I see filenames. That is an extremely important starting point - if I did not, I'd have to assume the file is encrypted, compressed, or does not use filenames at all, which are all harder to unpack.
For the moment, skip the header "BigFile" and the immedtaly following data and concentrate on these filenames alone.
If the filenames have different lengths, you can verify if these are records of a fixed length (where the filenames are padded), or have different lengths, in which case there may be a "length" value - or not. A length value may not be necessary, the file names can be terminated by a special value such as 0.
There are other values too - usually, in an archive format, these are file lengths. There can also be a file offset - but from where? (E,g., start of file, start of archive data excluding the header, start of actual data, and so on.) A per-file offset is not required if all files appear end to end, then the lengths are enough.
There may be additional information per file record; I have encountered flags, file type codes, date/time stamps, checksums, and more. Usually, after you found out what the most important bits mean, the remaining data makes sense as well.
To find out what byte means what, write a small program to print out each file name and all of its associated data, up to the next file entry. Don't bother with trying to get a correct 'file count' yet. Most likely this is one of the numbers in the header at the start; you can go back to that when you got the file list details right. For starters, just write out the data of the first few dozen of entries.
Keep in mind that you cannot tell right away if extra data comes before or after the file name! Or even both.
File sizes and offsets are usually 4 byte numbers; the endianness can be trivially checked (all small numbers are good, all conspicuously large must be an error). Similar but varying numbers may be file sizes. A number that keeps increasing must be an absolute file offset. Numbers that always contain data in some binary positions and none in others can be flags of some kind. Large values, hovering around similar values, can very well be a time stamp. Finally, random looking full 4 byte numbers might be a checksum.
If you get consistent good results in decoding the data for the test set of file records, find the start and end of the list by trial and error. It's here that you may discover that the "end" of a record is actually the start of the next one.
This will tell you (1) the number of records, and (2) the start of the record data. You can inspect if these numbers appear in the "BigFile" header - particularly the number of records would be useful.
If you can locate numbers that "look" like they could be file lengths and (optionally) offsets, you can write a test program to extract a single file. This may also help with determining the order of data; if you extract a file that is clearly a PNG image but its associated filename is "config.txt", you have something in the wrong order.
An alternative to the above is focussing on the data first. Some file types, such as PNG images, should be entirely self containing: if you find the start of a PNG image, you can immediately extract it in its entirety by looking for the tell-tale IEND marker. Then you have a reliable file length and so you can search for a match in the file record set.
