Super, że projekt się rozwija i coraz więcej rzeczy jest w nim zaimplementowanych, jednak zauważyłem, że to kolos na glinianych nogach — masz poważne braki w podstawach. Zdajesz się być kolejną ofiarą trendu rozpowszechnianego głównie przez youtubowych bieda-game deweloperów. I ten rak trawi branżę, niszcząc przede wszystkim początkujących koderów gier — nie liczy się funkcjonalność i jakość, a fajerwerki na ekranie, szybka gratyfikacja i aplauz.
Wspominam o tym dlatego, że brakuje mu choćby podstawowych danych — plik wykonywalny nie ma żadnej ikonki (nawet testowej), nie ma też uzupełnionych danych na temat nazwy programu, jego wersji czy informacji o twórcy i prawach autorskich (eksplorator systemowy i okno właściwości pliku nie pokazują żadnych niedomyślnych danych o pliku wykonywalnym). Te dane powinieneś wstępnie uzupełnić tuż po utworzeniu projektu w IDE.
Nie udało mi się uruchomić tej gry (o tym za chwilę), ale z danych, które podałeś (i ze zrzutów) wynika, że jedyne co ta gra posiada to obsługę mapy z aktorami i graczem, a także niektórych ficzerów rozgrywki. Zakładam, że nie masz tak podstawowych rzeczy jak choćby obsługa mapowania inputu (i wsparcia gamepadów), wsparcia trybu pełnoekranowego (desktopowego i ekskluzywnego), możliwości ustawienia parametrów pętli głównej (framerate oraz jego ograniczanie), wsparcia etapów (game stages) oraz innych fundamentalnych, niezwykle istotnych rzeczy.
Zabierasz się za ten projekt od końca, czyli od rozgrywki, ignorując fundament jakim jest silnik. Im dłużej będziesz zwlekał z dodaniem podstawowych rzeczy, tym więcej czasu później stracisz na ich implementację i dostosowywanie tego co już masz do nowych funkcji (bo cała rozgrywka będzie od nich zależeć). Istnieje też wysokie ryzyko, że np. implementując mapowanie inputu, cały kod rozgrywki będzie wymagał przepisania na nowo, co zeżre jeszcze więcej czasu.
Nie odbieraj tego posta jako ataku personalnego, bo nim nie jest. Jeśli chcesz dokończyć ten projekt i zapewnić mu wysoką jakość, natychmiast zakończ prace nad rozgrywką, wróć do podstaw silnika i zaimplementuj w nim ficzery, na których opierać się będzie dosłownie cała gra. Im szybciej i lepiej je zaimplementujesz, tym lepiej dla całego projektu i twojej motywacji do dalszych prac. Pamiętaj, że domu nie buduje się zaczynając od dachu, który ledwo trzymać się będzie na kominie.
Wracając do problemów technicznych — gra nie uruchamia się, bo odwołuje się do bibliotek dll, które nie istnieją w moim systemie (Windows 10, 22H2, z najświeższymi aktualizacjami). Brakuje poniższych bibliotek:
vcruntime140d.dllmsvcp140d.dllvcruntime140d_1d.dllucrtbased.dll
Obstawiam, że nie mam zainstalowanego czegoś pokroju Visual Studio, stąd brak tych bibliotek. Zainteresuj się tym tematem i kompiluj swój projekt w taki sposób, aby nie wymagał dodatkowych dll, a jeśli już, to dołącz je do instalacji/archiwum gry (o ile ich licencja na to pozwala). Nie używam SFML-a, bo to słaba i ssąca pałkę CPU biblioteka, więc tutaj rozwiązania musisz poszukać na własną rękę. Albo wywalić SFML-a i skorzystać z SDL-a, który żadnych zależności nie wymaga i działa wszędzie, w dodatku szybciej od SFML-a.
PS: mała rada — jeśli publikujesz zbiór wielu plików w formie pliku archiwum, to nie kompresuj katalogu z plikami, a znajdujące się w tym katalogu pliki. Jeśli spakujesz same pliki, to użytkownik będzie miał wybór: albo wypakować same pliki, albo wypakować je do konkretnego katalogu, proponowanego przez archiwizator (opcje Extract here oraz Extract to "foldername\").
Przez to, że pakujesz cały katalog, użytkownik traci taką możliwość — opcja Extract here wypakuje katalog z plikami, a Extract to "foldername\" wypakuje katalog, w którym będzie katalog, w którym będą pliki. To super-irytujące.
C++ 
Fistandantilus