Boulderbeast

[Bob the Hamster]

I just saw this:

http://www.slimesalad.com/forum/viewgame.php?t=3512

My mind is blown.

[camdog]

That is amazing! Those sin and cos scripts are brutal, though. Any chance we can get some advanced math functions built into the engine, James? (I guess its tough with only ints, but maybe you guys have been kicking around ideas?)

[Bob the Hamster]

Yes. TMC is working on some cool script interpreter cleanups, and when he is finished, we will not only have real strings and real arrays, we will have real floats too. Then we can add stuff like sin and cos as built-in commands.

[TwirlySocrates]

Glad you guys like it
I had to think really hard to get the beast on his feet!
The most difficult part was using a tree structure of slices to store variables. This will become vastly simplified when arrays become available.
The actual geometry isn't very complicated, and when I'm done, I'll provide better documentation and comments in the code.

I'm not done yet though:
1) I'll be animating the beast ... so, you know, walks, gestures, etc.
2) The boulderbeast's movements will use a simple physics simulation of a damped simple harmonic oscillator to give the impression of mass and inertia.
I did a simple test simulation, and it worked - but I have yet to try it on the beast. It might look terrible, but I suspect that if I specify a different mass, spring constant, and damping coefficient for each body part, it should look good.
This would be cool: if he's agitated, I can increase the spring constant to make it look like there's more tension in his body.
Anyways, we'll see how this goes.

In the meantime, if anyone has any experience with 3D visuals and can help me with the bug(?) I described in the game's posting, I'd be very thankful.

Btw: I didn't write those SIN/COS lookup tables by hand. I wrote a looped MATLAB script and printed everything to a text file

[TwirlySocrates]

I've updated the tech demo.

In addition to the puppet mode, you can make him walk around now.

[Skullduggery Studios]

That's insane, dude. Wow. Computer's being retarded and won't let me open the file ( ), but just the picture is amazing.

[TwirlySocrates]

Really?

Is that file not working?
Is that why people are still downloading my older version?
(Is that why someone voted me down from five stars? :-P)

I've been meaning to try and run it on my old computer ... I'll try that.

EDIT:
Works nicely on my 5 year old computer.
D'oh! I uploaded a .rpg file that was made using the latest nightly. I'm not using any new features ... but maybe that's the problem anyways.
Sorry about that.
I guess there really isn't a way to convert my .rpg file back, so really, what I'll do is just include a .exe file (Like I'm supposed to anyways).

Okay. Try it out now.

[Skullduggery Studios]

s'okay man. It was only the computer. I got it on another one and HOLYSLIMETHATISAWESOMEEVENTHOUGHIDIDN'TUNDERSTANDABITOFTHESCRIPTINGOHMYGOSHINCREDIBLE!!!

Now that that's out of my system... Wow.

[TwirlySocrates]

You can try and make your own if you like.

In SandS_BB.hss, the first script in the file is called "Create Boulderbeast". It's here where you designate what sprite goes to what body part. (It starts with a bunch of "LOAD SPRITE" commands - just enter the picture ID # and the pallette # you want for each body part)

So ... you could make a new beast out of rainbows and lollipops.

[Skullduggery Studios]

THAT part I understood. It was when you got into SIN and COS functions I got lost.

Geez, dude. I barely followed geometry and you're freakin' CODING in it. It's enough to make anyone play video games!

[TwirlySocrates]

Have you taken linear algebra, or done anything with vectors?
All of the Boulderbeast's slices are positioned using 3D vectors. Essentially what I'm doing is using this rule:

If I have a vector (x,y,z), I can rotate it by an angle Rz around the z axis using the formulae:

x' = x COS(Rz) - y SIN(Rz)
y' = x SIN(Rz) + y COS(Rz)
z' = z

I actually forget how to prove these equations. I only remembered them from class, and then looked them up on wikipedia.
http://en.wikipedia.org/wiki/Rotation_matrix

If you understand this, then the other two rotations around the y and x axes are built in a similar way.
(Oh, and the reason I divide by 1000000 in the code has nothing to do with geometry, and more to do with the fact that I'm using SIN and COS functions with integer only math)

For me, the math wasn't too hard. The difficult part was designing the Boulderbeast slice-tree data-structures. That was very hard, but now it's getting much easier. I've developed some slick tree traversals which make coding way easier (and I'm less likely to make any mistakes).

[msw188]

Not hard to prove. Immediate after proving some properties of matrix multiplication.

Out of curiosity, why did you call the angle Rz? I looked at that formula and thought to myself, "that's not right! You don't put the z-coordinate into the sin and cos, that would be silly!"

[TwirlySocrates]

Yeah, Wikipedia says that any orthogonal matrix with a determinant of 1 is a rotation matrix. If this is supposed to be self-evident to the reader ... well it's not

It seemed to me that there's a zillion different conventions when it comes to naming angles. I just thought it would be simple to define Ri as "The angle of right-handed rotation around axis i". I guess I could have used a Latex subscript: R_i
Hm ... if you've been following my CP and slime salad posts, I've referred to the rotation matrices as Rx Ry and Rz. Oops. Whatever.

While on the subject of mathematics and monsters, let's play a game! It's called, "Guess what TwirlySocrates is planning."
Two painfully vague hints:
1) I love monsters
2) http://en.wikipedia.org/wiki/B%C3%A9zier_curve

[Bob the Hamster]

While on the subject of mathematics and monsters, let's play a game! It's called, "Guess what TwirlySocrates is planning."
Two painfully vague hints:
1) I love monsters
2) http://en.wikipedia.org/wiki/B%C3%A9zier_curve

Loch Ness monster!

[msw188]

A 3x3 matrix can be defined according to the image of the three standard basis vectors i=(1,0,0), j=(0,1,0), k=(0,0,1) after multiplication. If the matrix is orthogonal, by definition, that means that these three images must remain orthogonal to each other and must have unit length. The determinant is the volume of the box 'spanned' by these images, and is negative if and only if the orientation of one of them has been flipped (ie, if the images i'xj'=-k' instead of k'). If you accept these facts, it doesn't take long to realize that an orthogonal matrix, with determinant one, must have taken the three basis vectors and kept them rigid with respect to each other, and so can only have rotated them or flipped them (and the determinant being +1, not -1, assures that the flipping wasn't what happened).

It's not proving much, really. In fact, most of the work is already done by the definition of "orthogonal". If you take the definition of orthogonal to be M(transpose)=M(inverse), there is a bit more work to be done to convince ourselves that this definition is equivalent to the images i', j', and k' being orthonormal (orthogonal AND all of unit length).

EDIT:
Or did you mean proving that any such rigid motion that wasn't a reflection must have been rotation around some fixed axis? Well, the simplest way to understand it may well be to realize that, as a 3x3 matrix, it's characteristic equation is degree 3 and so there must be at least one real eigenvalue, and thusly one eigenvector (and thusly one fixed axis). From there one can consider that the basis vectors, in relation to this fixed axis, did not change it, but they themselves remained rigid in relation to each other, so they can't have leaned any closer or farther from it. So they must have rotated about it. I'll admit that this is a bit hazy without an algebraic proof (or an above average visual grasp of "how linear things work")