Jump to content

Game table + hud help


Perc Waco
 Share

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

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

Recommended Posts

Hello. I have been pulling my hair all day today trying to figure a few things out with a project I have. I'm making game tables (spades, euchre, etc). It will use a hud for the gameplay while the table will just change which cards show up on the table as each player plays them. I'm not 100% familiar with object communication yet but have learned that it is pretty much done on a private channel.

That kind of set me back on the way I am looking to approach this. How would I keep each game table seperate in a way that they wouldn't interfere with other nearby tables and players? For example, two spades tables are sitting out nearby with 8 people looking to play a game of spades. 4 of them will go to one table and 4 to another. But how would I allow for the tables to detect who is playing at which table and what private channel commands to listen to?

Perhaps one of you may know of an already made script where a hud communicates with an object in world that I could look at for reference?

Also another question is with the cards and their textures. How is this approached aside from using a card deck sheet? Do I need to create 52 separate objects as the card deck and preplace the texture sheet on it with whatever offsets and then have the hud rez whichever card objects the player is dealt? Or is this done using some sort of texture replacement? Examples would be very helpful! Thanks in advance.

Link to comment
Share on other sites

Concerning the comm problem, a few different options come to my mind - and certainly others here have by far more brilliat ideas.

One possibility is, that each player 'logs in' to the table they are playing at. This logging in mechanism works on a common channel - the rest on a table specific channel which the table tells the HUD on logging in.

This logging in mechanism could be handled by a kind of server that makes sure, a player is only logged in to one table.

Instead of using different channel for each table, you could instanciate different listeners for the different players at each table or you use some kind of table specific pre-fix in the communication. I'm not sure, which way would be the most economic, but on first sight, I would prefer the channel solution.

As for the cards, I would, as you propose make a texture with a grid of all required cards. Usually, you have a define maximum number of cards in a certain position - e.g. there are 2 cards per player and 5 cards on the table at the max. in Texas Hold'em. I would place 2 cards in front of the player and 5 in the center - as long as the cards are hidden (not on the table) I would simply make them transparent, and as soon as they are shown, I would set alpa 1 and place the texture on it so the propper card is shown.

  • Like 1
Link to comment
Share on other sites

There's a few ways to keep players assigned to the right table. Aside from the already mentioned one, I'd go for another approach: When a player sits down at a table, you can get that players' UUID. Any HUD communication will allow you to query the owner UUID of the HUD, so you can simply have only the associated table respond. When avis stand up, simply remove them from the authorized players list.

Btw, you'll also want to encrypt or otherwise hide any game-relevant communication if you do care about fairness of the game. Probably the easiest way to solve this would be to use HTTP client/server communication (table is server, HUD is client) since that cannot be listened in on by scripts. You'll still need an initial conversation to establish the link, but beyond that it's be a private conversation. Alternatively, have a look at the crypto libraries in the wikis LSL library. They can hit the sims script engine hard though.

Texture...depends. I'd probably go for 52 textures and replace them as needed, with the texture size as small as you can get away with. Personal preference, really. Just don't use a 1024x1024 texture for a card that'll only display at (for example) 128x64px on the client.  :) The ideal texture solution depends a lot on your specific needs.

  • Like 1
Link to comment
Share on other sites

Thank you. I will chew on these ideas for awhile and go from there. Will see what other ideas others might suggest in the meantime as well, but I do like the login idea. I never thought about being able to detect who sat in a chair. This chair could simply tell the table and hud.

Link to comment
Share on other sites

Yes, my first thought was the same as Jenni's.  Detect when someone sits/stands.  When they sit have the table chat the 'private' communication channel, prefixed by that player's UUID, so their HUD knows it's for them.  After that use the private comms for all chat. (eg; table detects avatar abcd-1234 (etc) has sat, chats on /-5678 "abcd-1234:-8238".  That player's HUD knows that from now on it is to use /-8238 for communications.  This can be randomised/generated specific to the player's UUID or, as Jenni said, use HTTP).

There's certainly no need to make a separate object for each card.  Making a single texture with all the card-faces (plus a card-back) on them would be my choice - only one thing to change later, only one texture to rez, only one texture-UUID for the script to store, only L$10 to upload, but you may decide to make a texture for each card if you wish.  Changing the texture and/or offsets is the same operation so the processing doesn't matter.

Just as a final note, please remember that online gambling is illegal under Californian law which governs Linden Lab and so is illegal in SL.

  • Like 1
Link to comment
Share on other sites

of course there's always the simple method of limiting chat to a particular table.... have the table use LLWhisper, and make sure other tables players are more than 10m away. the players can be detected for listening to them specifically by detecting when they sit.

  • Like 1
Link to comment
Share on other sites

Hi Perc Waco,

I would suggest using a HUD and a table with the card positions defined on the table. This way instead of rezzing cards, you just change the texture on the pre-defined card position.The HUD can be used to display the player's hand and other options.

If you cant find what you're looking for , Drop me an IM or notecard and we can work on a solution.

Link to comment
Share on other sites

  • 2 years later...

Hi,

I don't have the time or knowledge to re-invent the wheel in terms of card game huds.  I'm a language teacher in SL, and I have combed the SL marketplace for a cardgame hud I can modify for language teaching purposes.  The are plenty of basic card game huds out there, but they are not modifiable or transferrable.  What to do?  What to do? 

I don't need a sophisticated hud.  I intend to simply replace regular card faces with words and/or pictures, then have the students draw 5 cards from a deck on a table in a way that permits only the person drawing the cards to see the cards.  When the drawer has a pair or trio, etc., I want him or her to be able to lay the cards on the table for everyone to see and discuss. 

Since I or some other teacher will always be present when the students are playing the games, the scripts and/or hud does not have to be very smart.   For example, the scripts or hud do not need to know the rules of the card game being played since getting the students to listen to and ask questions about the rules is one of the primary purposes of the activity.

I suppose I could just put 52 textures or notecards into a deck-type object with a giver script in it so that when the deck is touched, it gives out single textures in a random order until the deck is depleted. 

Notecards would work because they will only rez on their owner's screen when received.  But I can't put pictutes into notecards.  For pictures, I need to be able to give out textures, but textures pose a problem since they don't automatically open when received.  Because of these problems, a hud that can hold each player's cards would be helpful.

I supposed when it is time to "lay down" a hand, the students could just drop the notecards/textures into 5 notecard displaying objects.

Any wizards out there that can help me refine these ideas?


Thanks for any thoughts you might share,

Barbara Novelli

Link to comment
Share on other sites

  • 2 years later...

" But how would I allow for the tables to detect who is playing at which table and what private channel commands to listen to?"

http://wiki.secondlife.com/wiki/LlRegionSayTo

ADDED; I do not now think the above is really relevent as if the table and script are one then a simple child prim touch and place number is only needed. The child prim rezzes the card or changes the texture, the main script tells it to by link message. Would need no HUD. Just a thought.

As for your las question it would probably be faster to delete the rezzed card and rezz a new all the time recording which cards have been rezzed. As in ace spades rezz, record that it has been rezzed and dissalow it to be rezzed again.

A basic record script.

integer card;list cardlist=[];integer limit = 10000; // <- bytes This was only for this script.default{	changed(integer ch)	{		if(ch&CHANGED_OWNER)		{			llResetScript();		}	}	on_rez(integer num)	{		llResetScript();	}	state_entry()	{		llSetMemoryLimit(limit);//No point waisting resorces	}	touch_start(integer total_number)	{		card = (integer)(llFrand(52));//This you have to change 		if(~llListFindList(cardlist,(list)card))//Search to see if card is in the memory		{			llSay(0,(string)card+" You got a match, card number is "+(string)card);//I would keep this as a debug		}		else		{			llSay(0,"card number is "+(string)card);//There was no match in the memory, so your message would go here			cardlist += card;//Add card to list			cardlist = llListSort(cardlist, 1, TRUE);//I just like neatness		}	}}

 

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3029 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...