A link to the rules of the game?
1 Like
Here is a link that I found.
Only difference is that I've made the app only for 2 players, and when it's a tie, both the cards go to the 'bottom of the pile'.
Thank you for asking!
It would help if you were to show the Firebase DB tree structure, from the Firebase console.
Meanwhile, I'll start with a reading of Screen1:
The setting of the global players list is deadly:
It leaves the global list as a blank text instead of an empty list if blank text comes back from Firebase. That poisons subsequent list actions against that variable. Also, the global list does not contain the player's name. (I don't know if that is intentional or not. If it's intentional, the variable should be named OtherPlayers.)
...more to come ...
From your .docx, to keep this all together in the thread:
Players chance: “This player” or “Other player”
When a button is clicked, the following is sent to the Firebase:
Tag: Gameplay
Value: List of
- “Aircraft: [Aircraft name]”
- “Max speed: value”
Order of buttons:
- Max speed
- Length
- Thrust
- Max seats
- TO weight
- Range
Switching to Game screen – start value = List, index 1 = player name, index 2 = other player name, index 3 = starting player name
I skipped past how you pass data from Screen1 to game_screen, to see why I did not see a table of card deck values in your Media folder.
I found bad news, indicating that you have not used dictionaries or tables for the card deck:
Unfortunately, Discourse can't load the cleaned up blocks image for that screen, so I will show the mistakes snip by snip:
You have dozens of these:
You pay for that mistake in the Play procedure:
(again, too large for Discourse, with all its repeated code, so here's another snip)
I had to zoom out just to show the first two plane cards.
You need to learn tables and parametrized procedures to reduce your block count by 95%, or you might not pass a build.
Also, rubber stamping your code magnifies the cleanup if you made a mistake.
This makes sense. However, I'm not very familiar with using Dictionaries and the other things, so I may not be able to work it out well... What is my best way forward?
I'm still trying to get a grasp on your list knowledge and the data structures needed for this game.
Are multiple cards of the same type and value allowed in the deck?
That affects how to represent the deck internally.
BTW, this is a recipe for a coma at run time:
Were you looking to shuffle a deck?
Not really shuffling, just to ensure that the players don't have repeated cards. No cards can be repeated
Also, I had replaced this block with another procedure, but forgot to remove it. Fortunately, this procedure is not used anywhere.
To avoid retyping all that card data, you need some lookup functions:
cardData:
- input: text cardName ('Airbus_A340_600',...)
- output: that global variable holding that plane's data, in you case a list
attributeValue:
- inputs:
- text cardName ('Airbus_A340_600',...)
- text attributeName ('Max speed',...)
- output : lookup value of that attribute for that card
(This procedure knows how to lookup attributes by position in your cards)
displayComponent:
- input: text attributeName ('Max speed',...)
- output component: label component that displays that attribute (Max_speed,...)
Picture:
- input: text cardName ('Airbus_A340_600',...)
- output: picture file name for that card
This is a step towards generalizing the code, to allow plugging in new decks without extensive rework.
I have not penetrated your game play yet.
I've not really understood how I'm supposed to code this using blocks... Is this using dictionaries?
Please read chapter 21 of
http://www.appinventor.org/book2
to learn how to use parametrized procedures.
Still working on the game play.
From your link:
Wait for the player left of the dealer to choose a card and read 1 of the stats. Invite the first player to read over their card and choose a “stat,” or card description, with a high numerical value.
So the player that starts off a round is not forced to use the top card of his stack, and is allowed to look through his stack to see which card he can play?
I find code like this impossible to work with.
If you had encoded your deck in a Google Sheet, one row per plane, with headings over each attribute, you could have downloaded it as a CSV table into your app's Media folder, and read that table at run time.
All the lookups you do by hand could have collapsed like a telescope.
When it comes time for the app to compare attributes across cards, how is it supposed to compare values with '*' or ',' in them?
Those symbols break math operations.
The concept of table lookup is fundamental.
Used properly, they can remove a lot of burdensome detail from your code.
The AI2 list blocks have a simpler Lookup In Pairs block.
Here's a tip on building up compound Firebase tags:
If you put a '/' between the parts of your Firebase tag, it makes it easier to see the tag/value structure in the Firebase console. The '/' imposes a tree structure on the data, so you can adjust your bucket to zoom in on one branch and its sub-branches. That becomes useful if you want to run more than one game at a time. It also allows grabbing an entire branch and its sub-branches as a dictionary.
After sleeping on this game design, I have realized that it's doable without a shared data base if the apps sms with the dealer's device.
The dealer's device would keep all stacks by player name, and mediate all game play, telling the players their top cards and soliciting decisions as needed.
Thing is, there isn't a separate dealer, only 2 people and both playing...
Also, won't this really spam the SMS?
Right, the role of dealer can alternate among players.
I only send and receive less than a dozen SMS a week.
So, I suppose so.
I have not studied data plans.
It's a tradeoff against the expense and trouble of maintaining a shared database.
Ok, I'll think about how this can be done then.
Thank you so much for your time!
1 Like