1.) Is TDD applicable to game development? I'm guessing the answer is yes for large projects/teams, but I don't know about small project games like what I've mentioned I've done/am working on.
It's applicable to development, so game development would not be ruled out...but it is something that you'll find is practiced more widely outside of games than in, although there is no particular reason for that.
It can apply to small projects just as appropriately as it can to large projects. Larger projects are in some ways more difficult if the entire team is not using the technique, because other team members might break your tests or you'll keep the tests very small and based around what you author only, possibly at the sub-feature level.
But do remember there is more than one way to boil an egg. Some people get similar benefits by doing other things and some people just frankly have a preference for one thing over another. There is no single correct methodology and if there is a best one, it's often a mixture of things anyway.
2.) If it is, what kinds of tests would one run?
A test, which will likely be a set of smaller tests but collectively considered that validates whatever feature you're implementing. These will be tests that confirm you get an expected output for the given input, Fake and mock tests that simulate real use of the code, either in full or in part and so on. A test that takes you through the entire 'use case' of the feature or code, possibly from initialization, gathering the results/output and validating them as being valid and/or within certain constraints and testing even the destruction of the system to finish.
The general idea is that the tests also define your requirements, so TDD is often considered efficient because you're not authoring a whole lot of imaginary requirements or documents elsewhere, you're doing the requirements, the tests and the code pretty much all in the same place which many people consider is productive.
Also, it can also include tests that test memory and performance impact...particularly if you have specific requirements there.
If you are working on an object, you might run a test every once in a while to make sure the object is in a correct state at any one time, sometimes people try and keep an object in what is known as a class invariant state for example which basically means it's never broken between operations, or at least that kept to a minimum. I used to work at place where as part of their coding standard, each object had an 'invariant' function that would be asserted to be true at various points. Such a function can play a role in these tests.
Basically...whatever tests you want, but enough so to validate against your requirements. Anything less is not really TDD, although that doesn't necessarily mean less is not still valuable.
Is it a good idea/worth learning? etc
It's a good idea, but like many good ideas they often represent more of a personal preference and/or is going to be based on your own personal situation, the sort of code your are authoring and so on. Some people take to concepts like this well and others just feel it gets in the way, or they might not benefit from it much so it's nothing but overhead. It's productive and productivity is a good thing, but you need to figure out whether the productivity it offers you is valuable and/or enough to justify it.
Start small, definitely more at the class unit test level rather than testing higher level features and the entire output of a program or specific feature. This will let you dabble in it without diving in head first. i.e. if you're interested, do enough to figure out how much personal value this is to you and whether or not you want to spend more time on it.
Try and figure out whether it'll be productive for you at both the small and large scales i.e. at class level,more of at the class unit test level or at the feature level...or both (again thinking in terms of many small results sum to a big result). You'll have to also maintain, develop and iterate the tests you author so you need to understand whether that's overhead for you or not.
Ultimately, you need to determine that you can accept the overhead and consider it tolerable, understanding whether the net result of all the work still yields productivity or some other benefit that has value to you. You might actually suffer a productivity loss from any concept such as this, but consider that to be okay given the quality of code coming out of the other end. Again, that's a very personal decision and assessment. Programming is all about making trade offs and not all have black and white results.
Bear in mind that it can help to put together an extensive framework to run these tests. I don't recommend doing that initially, but there is a point where if you take this on running many little tests all the time by hand becomes cumbersome so do consider that if you run with this, it is quite inevitable you'll spend time automating the entire process. That will payoff in the long run, but there'll be a period in time where you're not working on new code and putting together a framework and build system.