Concept video: CC Pyramid Run

Creator, on 26 April 2015 - 10:55 PM said:

This is truly waesome. And you've got 500 subs. I think I've already watched you on YouTube Before

Bomb Bloke, on 27 April 2015 - 01:28 AM said:

That's outstanding. :)/>
…

Bomb Bloke, on 27 April 2015 - 01:28 AM said:

…
Are there any potential issues with mobs spawning due to lack of light? I'm fairly sure I spotted an extra zombie appearing at some point, and a creeper taking out one of those chests could be catastrophic for the player.
…

Bomb Bloke, on 27 April 2015 - 01:28 AM said:

…
Speaking of which, what happens if the player dies? Do they outright "lose", or is there some sort of respawn-at-a-penalty thing?
…

Bomb Bloke, on 27 April 2015 - 01:28 AM said:

…
I don't fancy myself as terribly imaginative, but I suppose if you wanted an idea for another room, you might make one with colour-coded teleport pads.

Another idea I once toyed with involved blocks of sand held up by other blocks; buttons or switches could be used to remove the supporting blocks, allowing the sand to fall into places where they could be used as "stepping stones".

Kaikaku, on 27 April 2015 - 08:29 PM said:

I could leave the player all gold ingots etc., take away all food and armor and give him instead a one-use pick, one block and a redstone. Hm?

Bomb Bloke, on 28 April 2015 - 03:14 AM said:

…
I suppose there's also the option of starting each player off with a wireless pocket computer, rigged to offer a single button that 1) teleports them just outside the front of their current pyramid, 2) resets their inventory back to what they started the game with, and 3) rebuilds that current pyramid from scratch. If they get stuck, they push the button. If they die, you run the same code.

If you do rebuild the maze, you'd need to ensure the player doesn't have anywhere to "hide" items (gold in particular). That is to say, once they get past the first pyramid, you'd block its exit off, and you'd also need to ensure they don't somehow bring chests to place onto the catwalk between the two areas (or just delete them if they do).

The same computer could, if you wanted, show them helpful information such as who's winning and perhaps even which rooms still have gold.

• (1) is a nice idea. So far (beside of decorative blocks) the player is only confronted with vanilla blocks in the pyramid. That's a left over design decision, from the time where I thought I could do a simpler version just with command blocks. I still don't want to scare players off with mod specific riddles, but I guess for ComputerCraft I could do an exception. And pocket computer with one touch button is not so sifficult to understood ;)/>

• Hm, I see there some issues for number (2), that I currently don't know how to solve.
In 1.7 you are quite limitted when it comes to check player (or chest) inventories. Think an item detection is not possible, only a deletion of items. I first tried to go with a scoreboard to track gold ingots or gold blocks. Scoreboards can be powerful and are some kind of displayable varibales for command block users (so far I only partly understand how to use them). However I figureed out, that in some cases (e.g. shift cklicking a block out of a crafting bench) a scoreboard is increased by two. So it is not reliable.

• (3) Atm I don't save the pyramid data. For the competitive mode with same pyramid set-up, I'll probably go for simultaneously building both pyramid sets.
However, saving the pyramid data will open possibilities for pre-build (easy/hard/complex/…) set-ups or also to exchange pyramid layouts including changing those data.

Kaikaku, on 28 April 2015 - 07:06 AM said:

Hm, I see there some issues for number (2), that I currently don't know how to solve.
In 1.7 you are quite limitted when it comes to check player (or chest) inventories. Think an item detection is not possible, only a deletion of items. I first tried to go with a scoreboard to track gold ingots or gold blocks. Scoreboards can be powerful and are some kind of displayable varibales for command block users (so far I only partly understand how to use them). However I figureed out, that in some cases (e.g. shift cklicking a block out of a crafting bench) a scoreboard is increased by two. So it is not reliable.

Bomb Bloke, on 28 April 2015 - 09:11 AM said:

When rebuilding, …

There's no need to "detect" anything.

Kaikaku, on 28 April 2015 - 10:07 PM said:

That's true, key is to save the pyramid data.

Kaikaku, on 28 April 2015 - 10:07 PM said:

Atm I'm using relative coordinates to teleport the player (so far I'm too lazy to calculate absolute coordinates). This restricts the room layout, as the player is usually not in the center of the pressure plate when triggering the redstone. So he might teleport into a wall. Hm, idea while writing this: I could put the pressure plates with the underlying teleporter one block lower in the ground. This would ensure that the player is nicely centered.

Bomb Bloke, on 29 April 2015 - 12:24 AM said:

…

Kaikaku, on 28 April 2015 - 10:07 PM said:

Atm I'm using relative coordinates to teleport the player (so far I'm too lazy to calculate absolute coordinates). This restricts the room layout, as the player is usually not in the center of the pressure plate when triggering the redstone. So he might teleport into a wall. Hm, idea while writing this: I could put the pressure plates with the underlying teleporter one block lower in the ground. This would ensure that the player is nicely centered.

Likely it'd be easier, in the end, to just calculate the absolute co-ords.

Bomb Bloke, on 25 April 2015 - 03:26 PM said:

…
Or, for added flexibility (allowing you to perform a command from multiple points within your main work loop, should you so choose):

Spoiler

-- variables
local maxCommands=250
local curCommands=0
local commandComputerCommand=""

-- functions
local function doOneCommand(commandComputerCommand)
  while curCommands >= maxCommands do os.pullEvent("task_complete") end
  commands.execAsync(commandComputerCommand)
  curCommands = curCommands + 1
end

local function pullTaskComplete()
  while true do
		os.pullEvent("task_complete")
		curCommands = curCommands - 1
  end
end

local function doWork()
  while true do
	-- building program stuff, incl.
	-- commandComputerCommand="..."

	doOneCommand(commandComputerCommand)
  end
end

-- main
parallel.waitForAny(pullTaskComplete,doWork)

…