1, I identified all of the functional dependencies here:
You have not identified all the FDs (functional dependencies) that hold. First: FDs are between sets of attributes. Although it happens that if we restrict ourselves to FDs from a set of attributes to a set holding a single attribute then we can infer what other FDs hold. So we can restrict what we mean by "all", but you should know what you are saying. Next: You have identified some FDs that hold. But all the ones implied by them via Armstrong's axioms also hold. This always means some trivial FDs, eg {Sport Centre} -> Sport Centre & {} -> {}. Although it happens that we can infer the trivial FDs just from knowing the attributes. So again we can restrict what we mean by "all", but you should know what you are saying. It happens that you have identified all the non-trivial FDs with one attribute on the RHS. But you have not justified that the ones you found hold or that you have found all the ones that hold.
You need to learn algorithms & relevant definitions for generating a description of the set of all FDs that hold. Including Armstrong's axioms, the notion of a FD transitive closure & the notion of a FD canonical cover to concisely characterize a closure.
2, I identified all candidate keys:
Assuming that { {Sport Centre} -> Sport } is a canonical cover, the only CK is {Name, Sport Centre}.
You need to learn algorithms & relevant definitions for finding all CKs.
I thought to be in BCNF that the table must have more than 1 candidate key
That's wrong. You seem to be trying to recall something like "3NF & not BCNF implies more than 1 CK" or "3NF & 1 CK implies BCNF", which are true. But these don't give that BCNF implies more than 1 CK, or equivalently, that 1 CK implies not BCNF.
You need to learn a definition of BCNF & other relevant definitions.
I'm unsure how to get this to BCNF.
We can always decompose to a BCNF design. Most definitions of BCNF say it is when there are no FDs of a certain form. It happens that we can get to BCNF by repeatedly losslessly decomposing to eliminate a problem FD. However, that might needlessly not "preserve" FDs. So we typically decompose with preservation to 3NF/EKNF first, which can always preserve FDs. Although then going to BCNF might fail to preserve a FD even though there was a FD-preserving decomposition directly from the original.
You need to learn algorithms & relevant definitions for decomposing to a given NF. Including the notions of lossless decomposition & FD preservation.
But I also understand that to be in 3NF (before BCNF) that every attribute must be dependant on the full primary key and my splitting up breaks this rule.
To normalize to a given NF it is not necessary to go through lower NFs. In general that can eliminate good final NF designs from arising.
Also "to be in 3NF [...] every attribute must be dependent on the full primary key" is not correct. You need to memorize definitions--necessary & sufficient conditions. And PKs (primary keys) do not matter to normalization, CKs do. Although we can investigate the special case of just one CK, which we could then refer to as the PK. Also "my splitting up breaks this rule" doesn't make sense. A necessary condition for a table to be in some NF is not a rule about how to decompose to it or any other NF.
You need to find a (good) academic textbook and learn its normalization definitions & algorithms. (Dozens of textbooks are free online, also slides & courses.) When you are stuck following it, reference & quote it, show your work following it, and explain about how you are stuck.
