Hand-wiring an 8x8 matrix vs just getting a driver chip, thoughts?

I did the direct wiring route on my own matrix project a couple of years back and honestly the dim columns never fully went away. With one row lit at a time, each column only gets current for a tiny slice of the refresh cycle, so the LEDs are running well below what they'd need to look evenly bright. Adding resistors on every column instead of just the rows evened mine out a bit, but there was still a visible difference between the edge columns and the middle ones. The flicker was a seprate problem. My loop had too much other stuff in it, so the scan rate dropped low enough to see. Moving the display code into a timer interrupt fixed that completly, and the game logic just wrote to a buffer. If you want to understand scanning properly, that buffer approach is the thing to learn.

My honest take for a uni project is that the hand-wired version is the better story. Being able to explain why your columns are dim, with actual reasoning about duty cycle, is worth more in a viva than a shiny display from a module. I've since built a second version with a driver chip and the brightness is perfect, but I was glad I did the painful one first. One practical tip if you stick with direct drive: sink the current thru the column pins rather than source it, since the Arduino handles more current on the sink side. That got mine noticeably brighter.

I went the module route and never looked back, but not because I couldn't do the manual version. I actually wired an 8x8 to a Uno by hand for a clock project and got it scanning fine after a weekend of messing about. The problem was the next three weekends, all spent on brightness balancing and flicker that came back every time I changed anything in the loop. The pins on a Uno just aren't built to feed a whole row of LEDs at once, so some unevenness is baked in no matter how clever your code gets. For a uni project with a deadline, my honest take is that the learning you're chasing lives somewhere else anyway. Understanding how the scanning works is a great skill, but you can learn it just as well on a project where the deadline doesn't matter. Buy the cheap driver board, get your snake moving, get your marks. Then do the hand-wired version over the summer break when you can actually enjoy the pain.

One thing I'd add from my own attempt: the dim columns got noticeably worse the more LEDs I lit in a row at once, so a snake game with a long body is basically the worst case for direct wiring. My clock only ever lit a handful of dots and it still bugged me.

I suspect that even if the code is perfectly optimized and you have accounted for the duty cycle issues, the stability of the voltage rails themselves might be the real culprit behind the observed flicker and uneven illumination. When you are trying to drive 128 individual LEDs, expecially if they are high-brightness, the sudden inrush current during the scanning process can cause a momentary drop in the power supply voltage, which obviously affects the brightness across all active columns. Have you considered adding a decoupling capacitor close to the power input of the matrix to help smooth out those sudden demands? Also, if you're using a single USB power source, you are quite likely under-powering the entire assembly.

Forget the timing of the main loop for a second. I found that my display issues weren't really a code problem, but a power stability thing. When I was driving a larger display earlier, I noticed the voltage dipped significantly whenever the row scan triggered. My setup required a sustained 150 milliamps just to maintain peak brightness across all pins simultaneously. If your power supply can't handle that peak demand, you're going to see brightness fluctuations no matter how optimized your scan rate is.

I was thinking about the physical wires connecting to the pins because I tried putting some togehter just using paperclips and tape before. It worked for testing but the connection kept moving around and everything looked messy. If I don't have a real solid connection, could that be making the display look wierd even if my code is perfect? I'm trying to figure out if it's the physical setup or something else causing the brightness issues.

I had a weird time working on a similar display project where the flicker wasn't about the loop speed at all. The issue turned out to be how cleanly I was generating the clock signal. Using a simple software delay for timing caused jitter, which meant the LEDs weren't being addressed in the exact same sequence every time. Switching to a hardware timer interrupt fixed it instantly. I used an old RTC chip just to clock the display, and that difference in signal stability was night and day. It made the uneven illumination vanish right up front.

Update: tried the power angle a couple of you raised. Moved the matrix off the Uno's 5V pin onto its own supply and stuck a capacitor across the rails. Flicker calmed down a lot, wich supports what was said about voltage dipping every time a row switches. Dim columns are still there though, so it really does sound like each column only getting lit for a tiny slice is the limit of this setup.