I asked in a comment on the question, and maybe the OP will reply about the randomness.

@mbomb007 My own. I doubt Joe Z will answer, he doesn't seem to be around anymore, unfortunately.

Personally, I think cycling might be alright, but maybe try to switch up the order. Or cycle through a longer pattern with a length that would be harder to notice. Like 50 or 100.

> Last seen Jan 2 at 5:08

I wouldn't cycle through them in the same order forever. That'd be too easy.

I think it needs to appear random at first glance, at the very least.

I'ts going to be easy, anyway... Gievn the cycle times...

But I'll probably do what you suggest.

What do you mean? When running CGOL, you can set the "step size"

So it runs faster

> Your program will receive input by manually changing the state of the automaton at a specific generation to represent an interrupt (e.g. moving a piece left or right, dropping it, rotating it, or randomly generating a new piece to place onto the grid), counting a specific number of generations as waiting time

Yes, but you can also make it run slower the same way. So if your objective is to win easily, you can anyway. I think the fact it is easier to win than a regular tetris isn't very relevant, is it?

So you'll set the step size to that number. And then the game will "tick" along at a standard rate. And you can click in the input squares or however you do input whenever you want.

And you can't really win tetris, anyway

Once you set up the game, you have to follow the OP's rules. You don't get to change the clock speed as the player.

And you don't get to pause and step through whatever generation you want.

I don't think that would fit the specs.

Anyways, perhaps this should be talked about here.

Well, the player is free to do whatever pleases him. It's me, the developer, who has to follow OP's rules. But I'm not the player of the Tetris game, in the end.

The number of generation steps between the piece falling is determined by me. The speed at which each generation advances is decided by the player.

I have no control of this.

It means you have to create the game in a way that the player can play it if they follow the rules.

And just assume that they will

So if the user is playing the game as intended, then it won't be any easier than regular Tetris.

Honestly, the hardest part of making the game would be finding a pattern that works nice for input, where you can actually see where to click when zoomed out far enough to play the game.

The way I understand the "counting a specific number of generations as waiting time" requirement is: I need to make the piece fall down at regular generation intervals (let's say 50000 generations). The actuall speed (in seconds) that this represents isn't specified, and does not need to be constant. And it's not in my control, anyway. So it can't be a requirement for me, can it?

No, this waiting time refers to the amount of time between input polling/interrupts.

AND game ticks

It's all part of the same thing.

You poll for input each tick, I think

Yes, of course, both. Averything has to be regular in GoL, anyway. But it's a time in generation steps, not in seconds.

PPCG, any ideas for what I can do for the next hour that isn't writing/answering challenges?

But you'll set the step and running speed so it can be played without waiting an hour

Hence the "step size"

You set the step size such that it runs with 30 ticks/second or something, so we can actually play the game.

Hey, you're still working on the Tetris thing? That's good to hear!

So I can go here and set the step size to a power of 2, and it will run at that speed for me.

There are other implementations where you can click to change the value of a cell while it's running, and that's what would be necessary to play it.

Yes, I will suggest a step size. But nothing prevents the player to pause or make it faster/slower. And they probably will. Because it's what is fun, actually. Looking at the gliders... If you really wanna play tetris, you'll probably use something easier. Well, we're discussing a detail, here, anyway.

So you have an implementation that has an option to choose step size in generations, running speed, and can be modified at those generations.

@dim What do you mean, lol? No they won't.

If they do, you can ignore that use case.

It's outside the scope.

If I saw it, I'd play the game to see if it'd work correctly or break later.

Although users might need to temporarily decrease the step size, to, say, zoom in on the few pixels used for input and not miss the game happening in that time

That's what I'm saying, you should have an entire meta-pixel of size where you can click

@LegionMammal978 Yes. You may see something in a few weeks, but I can't guarantee I'll succeed. It's a pain.

Or use a macro with arrow keys bound to moving the mouse to the exact pixel and clicking.

No decrease in step size or running speed should be necessary to play, IMHO

@mbomb007 But how would it work so clicking anywhere works? And besides, most implementations (Golly et al.) don't support active editing above a certain scale (1:1 cells/pixels)

Is there an implementation that supports placing a pattern on click, rather than filling one cell?

Maybe you could have something fill a meta-pixel on-click

@mbomb007 Actually, to make it playable, what I plan to do is to make a glider collide an eater, with nothing else around (about the size of a tile). When the glider is deleted, the glider passes, and it triggers the required stuff but it also recreates automatically another eater at the same place. So you don't have to zoom in/out to "play". You roughly select the zone, click suppr, and it's done.

Sorry, I meant when the "eater" is deleted...

← 56 messages moved from The Nineteenth Byte

@dim so you're working on your own implementation?