To expand on what Sean is saying, the way one typically goes about decoding a game's custom file format is to open it in a hex editor, and start inspecting values and trying to find values that map to known values in the game. For instance, if you have a file that is the data for an entity, and you know in game that entity has a hitpoint value of 1500, then you might look for the hex value 05DC in the file (or potentially the value DC05, depending on endianness). Then you could try changing that value in the file and see if it reflects in the game. And there is lots of nuance to that as well; 16-bit versus 32-bit values, float vs. integer, signed vs. unsigned, and the aforementioned endianness.
In your particular case, it does appear that there is some human-readable string data you might be able to alter, providing the mechanisms are in place in the game to find external/new files. That, of course, presumes that those are references to external files, and not just a header for in-line file contents (think a packfile where the data for each file is preceded by its filename). That further presupposes that there aren't any absolute offset values in the file that may become invalid if the string lengths are not exactly the same. But, even in this case, there are things you can look for. Given that there appears to be some structure to the file (repeating instances of file names and entity names/types), you can add up the number of bytes between those file name entries, then look for that value somewhere near the filenames. Then voila, you've now found where they store the length of the structure/binary data for each “entry”.
As Sean alluded to, this is a painstaking process to do without any information about the file format. Without documentation, or an existing tool that can read/write those files, you may be out of luck. I would do google searches for things like “gamename .ddf”, as well as the extension of the file you're inspecting.