Table name of Change Table Value behavior

TheGabfather

I love tables in GameSalad but I always find it troublesome the way Change Table Value isn't flexible with accepting table names. Does anyone know of a simple/short/easy workaround for this?

The game we're putting together right now makes use of 4 Tables, all structured the same way. Depending on which Level you are on, the Table the game will be using will be different. So Level 1 makes use of the Table "1", etc.
Right now it's messy with 4 Rules that check what Level you are on, then basically fire the same Change Table Value rule (albeit with differing Table Names).

If tableCellValue can accept Table Names via use of Attributes, I wonder why Change Table Value cannot.
Edit: It seems tableCellValue also cannot accept attributes as Table Name? What a fluke my earlier test was :P

RThurman

One way I have found useful is to just have one long table that is divided into several sections.

For example, say you have four tables that each contain 300 questions. Just combine them into one table that has 1200 rows. Rows 1-300 correspond to Table1, Rows 301-600 correspond to Table2, Rows 601-999 correspond to Table3, and Rows 901-1200 correspond to Table 4.

Use an attribute called "Level#" to designate which 'set' of rows to access. And use an attribute called "Question#" to designate which row to access. Then all you have to do is multiply "Level#" by "Question#" to get the correct row.

For example, say you wanted to access question 235 of level 3 (formerly table 3). The behaviors would go something like this:

Change Attribute: self.Level# To: 3
Change Attribute: self.Question# To: 235
Change Attribute: self.MyQuestion To: tableCellValue(game.QuestionBank ,(self.Level# * self.Question#),1)

And you should get the contents of row 705 (that is 3*235).

gyroscope

Agree with @RThurman and @tatiang here, especially as you say your levels all happen on the same scene...

Another way to approach it as well - especially as you say your tables are all structured the same way - would be to have more columns; a column (or two, depending on what info you're storing) for each level, also all in the one table. (Actually, this could be made to work even if your levels were separate scenes too).

CodeMonkey

Copy a table to a generic table. Use the generic table for all your modifications and logic, then copy it back to the original table when needed.

gyroscope

Hi @TheGabfather I'm not seeing any advantage if we could use attributes in the table name selection of the Change Table Value behaviour...

Especially in this case you've described, where you'd still need to show a Change Table Value Behaviour 4 times, one for each level, surely, so why not then just select the appropriate table name for each level.... or perhaps I've missed your point...

TheGabfather

@gyroscope in our case, we're making a quiz game that has a single game scene for all four levels. We're making do with 2 game attributes that dictate what level you are on and what question you are currently trying to answer.

Inside each table besides listing all possible answers for the questions, we're including one boolean field to flag if the question has already been answered correctly.

In this case, if we imagine a Change Table Value behavior that can accept an attribute as a table name, we can feed it for example, the game attribute which stores which level you are currently on - therefore we only use one behavior to enter the correct table and look for the specific boolean field to edit.

No need to write 4 Rules checking if game attribute 'Level Entered' is equal to '1', '2', etc. We're basically trying to make do with as few Rules as possible.

Boy, took me a while to try and explain this. Perhaps I'm just bad at explaining, that's why it seemed off

tatiang

Have to agree that where quiz-type games are concerned, it's 4 or 5 times the work to create rules for multiple tables. Being able to use table names as attributes would not only cut down on a serious amount of time but also make the code a lot cleaner.

And @RThurman it's a very good idea and one I've tried. I feel okay doing that for my own apps but when it comes to working for clients, I don't like to make things overly complex for them. So it's multiple tables and multiple rules. Although your approach with a level number is actually pretty clean so maybe I'll reconsider. Still hoping we get table name attribute support though.

tatiang

@gyroscope My current game has 400+ columns in each table. I'm not arguing with your good suggestion but it's cumbersome at best to deal with that info in GS Creator and it's not always better to view it in Excel while working on the project. Anyway, I'm appreciative of the generation of ideas here!

tatiang

@CodeMonkey now that idea I like!

TheGabfather

@RThurman I suppose for a small game like this one where I only have 160 rows total, that should work. In fact, I've already implemented it. Still hoping for a cleaner solution though or better yet, a revamped Change Table Value behavior before Creator v1.0.

@CodeMonkey 4AM, I hope I'm just missing something here, but wouldn't you still need to fire up a Rule/set of Rules to know which table to copy over to the generic table?

tatiang

I think so:

When game.level=1 --> Copy Table [Level1Table] to [GenericTable]
When game.level=2 --> Copy Table [Level2Table] to [GenericTable]
When game.level=3 --> Copy Table [Level3Table] to [GenericTable]
When game.level=4 --> Copy Table [Level4Table] to [GenericTable]

But that's one short set of rules compared to changing it for every level for every rule needed.

TheGabfather

Then I suppose it's a toss between that, and combining multiple tables together (provided they're manageable in size).

Cheers

ericzingeler

Copy a table to a generic table. Use the generic table for all your modifications and logic, then copy it back to the original table when needed.

This is the method I use.

SnapFireStudios

I agree that these are all fine workarounds, but it'd sure be nice if we could just type the table's name to access it instead of having to select it among the game attributes.
At the very least tables should be in their own Tables tab when attempting to access them like this.
- Thomas

tatiang

@SnapFireStudios I always name my tables |T| Words, |T| Levels, etc. It makes it much easier to see them in the long list of game attributes.

SnapFireStudios

@tatiang - I do the same exact thing, but shouldn't they have their own tab?
- Thomas

DocJ

@RThurman I know this goes back a bit for you, but I've been trying to wrap my head around your suggestion of combining the tables into one.
Currently I have 5 tables of 8 rows each. If I utilize your suggestion and combine them into one table. Let's say for example I wanted to access the 2nd row of the second set; by the theory above, if I had level 2* question 2, I would get the 4th row in the first set.
The only work around I can see is if somehow you can identify which rows go with which level.

I hope that makes sense, and thank you for looking at this
Doc

tatiang

@DocJ

The second row of the second set would be at row 10 which is calculated using (game.set-1) * 8 + 2, where game.set is 2. The third row of the fourth set would be at row 27 which is calculated using (game.set-1) * 8 + 3, where game.set is 4.

The generic equation is (game.set-1) * [number of rows per set] + [desired row number within set].

RThurman

Yes, I see that the original suggestion had a few calculation errors. Mea culpa! Here is an example of what to do. (Basically about the same as @tatiang is recommending.)

DocJ

@tatiang and @RThurman Thank you. This definitely explains things much better. RThurman, the examples you sent over work fantastic picking random levels and random rows. I can definitely see where this will come in handy. Nice, clean work.

Tatiang, you're more familiar with my project. This works great with the setup I have.

I know 5 tables (now 8 rows instead of the original 6) isn't a lot of data, and probably wouldn't slow up the game, but I wanted to see if I could do what you guys were talking about above. At the very least, I wanted to learn more about working with tables.

I'm going to continue this in another thread because I want to ask some opinions on specific items dealing with my project

Again, I thank you guys both very much for your input and help.

RThurman

You are welcome!

Armelline

Still hoping we get the ability to reference tables without these workarounds. They're great tips but only take you so far

DocJ

@Armelline since this thread goes back 2 years, and it's a concern among members, why haven't they addressed it? Is it something that's not possible?

Armelline

@DocJ said:
Armelline since this thread goes back 2 years, and it's a concern among members, why haven't they addressed it? Is it something that's not possible?

It's fairly common for there to be small features that would make big quality of life improvements to many users that go unaddressed for years (literally) since they're not flashy like new ad services etc. Improvements often go completely ignored or based on popular vote. And things like this aren't popular enough

DocJ

@Armelline Maybe it will pick up in popularity as tables gain more and more use among the members.
If there's a suggestion thread, or place to vote on updates, I'll vote for it.

P.S. Great job on the Illustrated Guides you've been putting together.

Armelline

@DocJ said:
Armelline Maybe it will pick up in popularity as tables gain more and more use among the members.
If there's a suggestion thread, or place to vote on updates, I'll vote for it.

There's no specific bug/feature request for it that I could see, but it's very much along the same lines as this one:

http://bugs.gamesalad.com/show_bug.cgi?id=259

Perhaps add a comment to that one suggesting the same flexibility for table name references, or create a feature request of your own.

P.S. Great job on the Illustrated Guides you've been putting together.

Thank you very much!