You have put all information in one table, which will be more difficult to handle and doesn't work with my example. It will be easier to handle everything if you put each score (that contain name, points and money) into its own table inside the one main table. The whole thing is nested tables then...
This would be compatible with my example:
Code: Select all
hallfametable={
{name="Joe", points=100, money=200},
{name="Juan", points=85, money=545},
{name="Lucia", points=78, money=123},
{name="Ines", points=45, money=289},
{name="Rene", points=21, money=127},
{name="Megan", points=20, money=521},
{name="Manuel", points=15, money=234},
{name="Rodrigo", points=6, money=13},
{name="Laura", points=5, money=56},
{name="Jack", points=4, money=129}
}
Or you could create the initial table using the p_AddScore function I made:
p_AddScore("Joe", 100, 200)
p_AddScore("Juan", 85, 545)
p_AddScore("Lucia", 78, 123)
...and so on...
Then each score with all its information is a single item in the hallfametable, and you can remove a whole score easily, for example RemoveItem(hallfametable, 2) would remove Lucia's score totallly.
If you don't like string indices, you could do this also like:
Code: Select all
hallfametable={
{"Joe", 100, 200},
{"Juan", 85, 545},
{"Lucia", 78, 123},
...and so on...
}
But then you have to use hallfametable[j][0] for the name, hallfametable[j][1] for the points, and hallfametable[j][2] for money. It would be shorter code, but harder to remember and read...
So, I would prefer use string indieces where you can just use hallfametable[j].name (or hallfametable[j]["name"]) just like in my example... it makes it easier to understand the code afterwards.