Parsing Game Entities
First, we encounter interface IParse.


public interface IParse {
    void Parse(string[] txtFile);
    void Add(List&lt;char&gt; map);
}



You should use C# conventions.


interface name should be a noun or noun phrase IParse -> IParser
use a plural name for a variable that represents a sequence of items txtFile -> segments?? 
use a meaningful name to describe structures map -> ?? -> doesn't say anything
use the correct types, preferrably interfaces, when dealing with sequences; For instance, IEnumerable to iterate, IList to manipulate.
Note that your interface does not have any state or return values. We are never able to interact with it bi-directionally. Too much encapsulation perhaps?


Refactored:

public interface IParser {
    void Parse(IEnumerable&lt;string&gt; segments); // or whatever we are talking about ?
    void Add(IList&lt;char&gt; map); // what is map ?
}


Let's move on to ParseObstacles.

Your state is public, is this as designed or a code smell? Again, use conventions.


public Dictionary&lt;char, string&gt; Dict;
public List&lt;Entity&gt; Entities;



private IDictionary&lt;char, string&gt; values; // they are values I suppose
private IList&lt;Entity&gt; entities;


Next, we find method Parse. 


the signature is already changed by interface implementation
Only use i as an index in an iterator
perform i.Split(')') once
Dict is already renamed previously



public void Parse(string[] txtFile) {
    foreach (var i in txtFile) {
        if (i.Contains(")")) {
            var tile = i.Split(')')[0].ToCharArray()[0];
            var name = i.Split(')')[1].Trim();
            Dict.Add(tile, name);
        }
    }
}



After changing the method:

 public void Parse(IEnumerable&lt;string&gt; segments) {
      foreach (var segment in segments) {
          if (segment.Contains(")")) {
              var tokens = segment.Split(')');
              var tile = tokens[0].ToCharArray()[0];
              var name = tokens[1].Trim();
              values.Add(tile, name);
          }
      }
 }


Next up, method Add. This is a black-box for us. Consider the fact ParseHelper adds cyclomatic complexity to your API. Perhaps its code should be divided into the other classes.


public void Add(List&lt;char&gt; map) {
     ParseHelper.AddEntities(map, Dict, Entities);
}



public void Add(IList&lt;char&gt; map) {
       // not convinced about ParseHelper ..
       ParseHelper.AddEntities(map, values, entities);
}


And finally, ParserFacade.

Let's have a look at the singleton. 


A private constructor, well done. 
A nested static class holding the singleton, good design. 
all caps -> take it easy: INSTANCE -> Instance 
a getter method is best substituted with a property getter: getInstance() -> Instance



private ParserFacade() { }

private static class ParserFacadeHolder {
    public static readonly ParserFacade INSTANCE = new ParserFacade();
}

public static ParserFacade getInstance() {
    return ParserFacadeHolder.INSTANCE;
}



After changes:

private static class ParserFacadeHolder {
    public static readonly ParserFacade Instance = new ParserFacade();
}

public static ParserFacade Instance =&gt; ParserFacadeHolder.Instance;


I don't like this helper class, but I did expect it to be static. Here you used an instance.


  private ParseHelper parseHelper;


Public state detected. Code smell?


 public ParseExits exits;
 public ParseObstacles obstacles;
 public ParsePlatforms platforms;
 public ParseCustomers customers;



Method StartParse:

What bothers me here is the inconsistent and convoluted design of parsing behavior. ParseExits (and sibling classes) can parse the file. But then the facade calls the infamous helper to parse additional data, to then forward this data to ParseExits. This design is too complex in behavioral complexity.


 exits = new ParseExits();
 exits.Parse(file);
 exits.Add(ParseHelper.GetAllTiles(file));