LAN Topology - more
In Figure 1 you will notice that all switches connect directly to a port on the core switch. (This is usually referred to as a "star" topology.) If you were to "cascade" switches in your LAN topology (Figure 2) - plugging additional switches into the floor or table switches instead of into the core - you would be introducing additional potential points of failure that will be difficult to track down. You'll also potentially place additional strain on the uplink ports to the core switch because more nodes will be feeding the port.
Figure 2: Not the way to connect switches
The probability of 24 100 Mbps connections completely filling a 1000 Mbps uplink is much lower then 48 or more 100 Mbps links. Don't cascade switches unless someone is holding a gun to your head (or you're risking possible lynching by 24 gamers that can't get on the LAN because your last uplink is taken!)
Gigabit vs. Fast Etherchannel
As you've read earlier, traffic patterns on a LAN Party's network are very random and unpredictable, so it's very important to provide enough bandwidth between the table switches and the "core" of the network for a number of people at a given switch to be sending or receiving traffic at full speed across their connection.
What this means is, if you have two or three people transferring at 100 Mbps to / from a given server (maybe they're downloading a game patch, or a hot new game demo) their traffic should not be creating a bottleneck with the other players on the same switch who may be playing low bandwidth, low latency games and / or running Voice over IP applications. The sum of their bandwidth needs to be below the total available bandwidth through to the core of the network.
In this example, a combined 300 Mbps of bandwidth is required for the high bandwidth applications, so at least that amount should be available. This is best achieved by connecting all of the table switches using gigabit Ethernet connections. It is also possible to connect tables to a core by multiple 100 Mbps connections using a technology called Fast EtherChannel, invented by Cisco Networks.
However, this method has inefficiencies that may prevent you from achieving the full potential of the combined bandwidth available. In addition to not being as efficient or as fast as gigabit Ethernet, you will also spend more money on more expensive fully "managed" switches that are required to configure multiple ports for Fast Etherchannel at both ends of the link.
Server Connectivity and Reliability Tips
In small and medium sized LANs with one or two switches, servers can be connected to either switch. However, in larger networks with core switches, more careful server connection is required. The suggested LAN topology in Figure 1 shows a server row switch connected to the core switch via redundant gigabit links. Game servers should generally be connected here, once again, to maximize performance and simply troubleshooting.
I also recommend that servers used for basic network services such as DNS, DHCP and Internet connectivity be connected directly to the core switch. This places the network services provided by these systems within a single hop from any location on the network.
Many LAN Parties run tournaments that require the highest reliability possible. Those servers should be connected directly to the core switch as long as ports are available. Other servers either brought in by participants or by the party staff can be plugged into the server row switch. The server row switch is still quite important in comparison to table switches since players from a number of tables will likely be playing off of these servers.
As mentioned above, I recommend that the server row switch be connected to the core switch via redundant gigabit Ethernet connections. While the bandwidth of dual gigabit is almost certainly not likely to be needed, the hot redundancy provided is essential to keeping everything running smoothly. Modern switches implement a technology called Rapid Spanning Tree Protocol (RSTP) that works like a dream in failing over from one link to another with only a split second pause. Tests in live scenarios with hundreds of connections showed that all connections transparently moved to the alternate link and not a single user noticed the failover!