Jump to content

Request : Twister in SL (Payments to discuss)


Bas Curtiz
 Share

You are about to reply to a thread that has been inactive for 4455 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Thought someone might be interested in making this wet dream of me **bleep** true ^

How about Twister in SL?
Likes where u can have fun with your friends (2 people or even more), where u can place your hands and feet in weird posish, on the Twister-mat?

That'll be soooo awesome, if u ask me:)

Atleast tell me what u think, if it's possible, if u wanna make it, hell, even sell it for all ppl out there, or just me.

I love to hear from u.

I'm open to pay u a good price, let's negoiate!

Bas Curtiz

Link to comment
Share on other sites

Now, I'm not the best scripter out there yet, but here's my two cents.

 

You'll need either animation sets for each general pose of the game, or to be comfortable with forcing contortion of characters in script. Either way, each Circle will need code that tells your character to change their animation, or attatch their body part to it. Each Circle will need an if statement that refuses to let a character attatch to it IF someone else is already on that square.

You'll need a Random Number Generator, actually two of them in one machine. One for body parts, and one for colors. Store as currentBody, and currentColor, place results into those variables every time. An exception for forced play would need tossed in if the same number comes up twice in a row, or if that rule is currently in effect. It could be touch based, or timed, depending on your preference.

That said, storage variables for each body part that dictate what happen would also be used, and swapped out by spin results that match the body part. The Spinner/Number-Generator would also need to send a message on a silent channel, like 123 or something, with each Circle having a Listen state, to share the info of the turn. You can't change your leg to blue if red was spun! That's how such rules would be implimented.

Ultimately, the issue is that since characters are used, not true bodies, nobody will "fall". Another RNG could exist, to make you randomly fall, but that's kinda uncool since Twister is a flexibility/skill game. I suppose you could assign values to each tile used, in a way that you could choose which player positionings are the highest risk poses, and use them as variables to modify the RNG, making it easier to roll a falling number the harder the pose.

Seeing as I suck with animations and body moding, and am average at best with scripting, this is all I have. A fall animation, position animations, a few rngs, a difficulty formula based on what should be contortion, and people who are willing to not cheat or grief is what you'll need, plus a good scripter and potentially a good animator, pending.

 

Oh! Almost forgot, you'd probably need a worn item of some sort, to initialize players. And of course, the player will have to authorize the item to animate/deanimate them, which is where cheating becomes a factor. If they refuse the fall animation, they're annoying. Odds are, they'd be asked each turn if they wanted to allow the object to act on them, which could lessen the fun. But hell, I've tried to puzzle it out in English, hopefully give some people a bit of inspiration or a head start, yeah? Or a basis on which to figure how much they want to charge for it.

Link to comment
Share on other sites

I gave this some thought a while back and decided not to try it.

There are two approaches, both with difficulties.  It's a very nontrivial game.

I scripted a Spin The Bottle game, which was a lot more complicated than I expected (with a bastardized MLPV2 script to do the posing), and it's way way way simpler in concept than Twister.

I wouldn't need objects for the spots (or code in the spots) or objects to be worn, doing it the way I would plan, but maybe there are approaches I haven't considered.  Other than that, archsagesoren makes a number of good points.

The simplest approach would involve completely premeditated games (or nearly so, more on that later).  For each premeditated (pre-planned) game, you'd have a predetermined animation for each turn in the game.  For example:

turn 1: player 1 spins left foot blue, script poses player with his left foot on the 2nd blue spot.

Turn 2: player 2 spins right hand red; script poses player with her right hand on 3rd red spot.

etc, etc ... once you start down a path, the result is always the same.

Now, with very clever analysis and crafting of the poses, instead of just a number of fixed independent games, you could plan a number of trees of games, where, from any preplanned position, you have more than one preplanned positions for the players to "spin", selecting from among them using a random number generator.  This would be a LOT of work but could be fun.

With even more thought, the "trees" might have branches that join up (that is, two different paths to reach the same pose) e.g., one where he places his foot on a given spot first, and then his hand on another, versus doing the same in the opposite order.  This has to be done carefully to avoid intersecting bodies!

The fun part would be the final turn for each branch in the tree, where an impossible move is spun, and the game concludes with an amusing animation where the players collapse in a heap.

The other option would be considerably more complicated, and involves a set of poses created by someone already.  I don't recall the name, but that system has hundreds and hundreds of animations to allow creating poses in SL, the anims move one joint, and say for right knee there are a large number moving in 5 degree increments on the allowable axes.

Someone who's REALLY clever might figure out how to use that kind of system.  I shudder to think, but there are plenty of clever people in the world!

I coded MLPV2 (a free menu system that's used in lots of menu-pose furniture) and it's not a trivial script.  Spin the Bottle was conceptually more of a challenge, involving a master controller script and MLPV2 to do the animation.  The result is fairly complicated.  But it pales in comparison to the kind of planning that would have to go into a system like this.

Using the first option above, I'd again use MLPV2 as the pose engine and have a master script to control it and run the game.  The master script would read a notecard that lists the possible game steps (defined as a tree using labels, probably), with a pose name as the result of each node in the tree.  I'd suggest anyone look at the ~sequencer script to see how a script can operate MLPV2.  It wouldn't need the modifications that Spin The Bottle needs, since it would only animate the current players.

Maybe someday if I end up with lots of free time I'll do this.  It really would be a lot of fun, especially if someone can help come up with a lot of fun trees of poses.  And knowing me, I'd probaby have a baudy version.

Meanwhile, anyone is free to try these ideas and I wish you luck!

Link to comment
Share on other sites


archsagesoren wrote:

If they refuse the fall animation, they're annoying. Odds are, they'd be asked each turn if they wanted to allow the object to act on them, which could lessen the fun. But hell, I've tried to puzzle it out in English, hopefully give some people a bit of inspiration or a head start, yeah? Or a basis on which to figure how much they want to charge for it.

This is not an issue.  If you've used a pose menu or poseball with multiple poses, you'll remember that you grant permission (to the script) once, and it keeps it as long as it wants to.  It can even keep permission after you stand or leave for days and come back, as long as nobody else granted it permission in the meantime.  I had to fix a number of MLP bugs in this area.  It used to be amusing to watch people being animated after they'd hopped off a bed.

Link to comment
Share on other sites

Interesting. I simply remembered a dance animator I saw in-game that required permission for each dance, and to stop animation, each time. I was rather certain it required permission for the same animation you allowed earlier if you switched back and forth real quick. I didn't have access to its source script, so I can't say with 100% certainty what they did to make that happen, or why.

Simple mistake in my use of human memory. Remembered the one occasion and applied it as a rule, which is rarely logically sound.

Also, your ideas on the Twister board do seem quite interesting. It reminds me more of how a Twister mod would work in The Sims, with the animation trees and predetermined possible outcomes. Seems less likely to bug out, and allows you to focus more on the visual side rather than the gaming side. It'd be more fun for the people whose games run slowly as well, a timed opportunity to get a circle would be rough on those with older rigs... But those oversights are part of why I'm still just a novice. Really just glad to see other people looking at this; it'd be quite fun in-game if anyone decides to shoulder the rather heavy looking burden of making it.

Link to comment
Share on other sites

Your memory is correct.  There is a good reason many danceballs work that way.

A script can hold permissions for at most one avatar.  A danceball that handles 30 dancers and only asks for permission once for each dancer would need at least 30 scripts.  So the simple one-script solution is to ask every time.  A bit of a nuisance for the users, but sure saves on server memory.

Of course, with Mono, the slave scripts that hold the permissions could be very small and take very little memory, and the code segment for them all is shared, so it wouldn't really be as bad as it might seem when looking at parcel memory usage.  But I digress. ;-)

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4455 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...