Guild of Writers

I have an idea, not sure if i'll implement it when animations are implemented.

The idea is a simple Rubiks cube puzzle, and seen a physical puzzle available in shops, we all know the famous 3 x 3 puzzle cube, but I have never been able to solve it, but I could solve a 2 x 2 puzzle.

Using this idea as an example, how would one attempt to code it?

I know its an XY type puzzle with UV axes for rotating the whole cube.


I don't know much about Python, but I do have a book on learning it, but as with everything, I need a real world reason to make/code it, a puzzle like this is a good starting point for all I think.

You could actually implement it without animations. Animations are going to be icing on the cake here, because what you really want to do is implement a cube with faces that change color. And then write code that changes the face colors according to the rules of Rubik cube rotation.

Then, when animations work, you'd have an animation that rotates a slice of the cube by 90 degrees... and then *snaps it back* at the same time that the face colors change. So it would *look* like a smooth rotation.

(I think this snapping-back idea is the way to go. Accumulating rotations might be possible, but I don't recommend it, because it would be very hard for the code -- the Age -- to decide when the puzzle is solved. If you base the puzzle on changing face colors, you can pretty easily write a test to determine if each face is a constant color.)

I'm not going to try to give you code, because I haven't sat down to work through the Plasma world-state system. But you'd basically have an object with 24 fields, corresponding to the 24 tiles of a 2x2x2 cube. Each one would control the texture of one polygon of the cube.

Personally I'd just simplify the problem and make the cube 1x1.

heh I was thinking the same thing grogyan at one time, but with my time constraints I kinda didn't get far. I did do a google search about it and found this though.

http://www.youtube.com/watch?v=ITxSBc3apKc

And this is him explaining how he did it in 3dsmax.

http://www.youtube.com/watch?v=L7o_RRC4mqU&feature=user


and this one as well. http://www.youtube.com/watch?v=qgf_iy38Q0w&feature=related

Was rather simple when he explained it and I was think within the same idea, but I'm not sure if it can be done with blender like he did it in max. There is a algorithm that can be used to solve a rubix cube.

Thats neat, but useless unfortunately, its based on 3D Max.

I can make a set of cubes like they suggested, thats easy, but assigning them as moveable/rotating objects within the scope of Uru as a puzzle, that I don't know, nor is there any tutorial to follow, puzzle, gui's.
What side of the cube to show as front, what the expected condition is and so on.

To my knowledge the only person to have a functioning puzzle is RtR in his Shell, and I doubt Rob will tell us how he did it.

Grogyan wrote:To my knowledge the only person to have a functioning puzzle is RtR in his Shell, and I doubt Rob will tell us how he did it.

I guess you must not have played many user ages because quite a few of them have puzzles. The german team has made several advanced puzzles. And there was MercAngel's Maze which would create different mazes by the press of a button.

IMO the best way to make this type of puzzle is using conditional objects. You could make different objects representing different rotation states of the cubes and show/hide them as needed. That will be a lot of objects (but not nearly as many as the maze had).

Using SDL variables also has the advantage that the current puzzle state will be immediately saved to the age state. So you will not have to restart the puzzle each time you return and in a multiplayer environment new arrivals can receive the current state as they link in.

And as belford said, animations could be the icing on the cake which can be added later once PyPRP supports them. btw, Robert must have used a Python animation using a timer.

The new interface should support any type of SDL cyan has implemented btw.

Trylon wrote:The new interface should support any type of SDL cyan has implemented btw.

Ok, thanks. But let it be noted that we can do that already without PyPRP.

Knew that.

Unfortunately the number of rotational states of a cube -- even 2x2x2 -- is kind of enormous. Maybe 120960? Probably some of those are unreachable, so it might be a third or a sixth of that, but it's still too big to create one of each.

You *could* create 24 face squares, each in six colors, which is 144 square objects, which is within reason. But I still think you'll be happier if you create 24 objects and then figure out how to change the displayed texture of each one.