Kupię kod gry / silnik


#1

Cześć,
mój pierwszy post, ale możecie sprawdzić mnie poprzez ceidg lub moją stronę appg.pl.

Mam pewien pomysł na grę, który opiera się o niezwykłą precyzję. Niestety dostępne silniki są oparte o to co najważniejsze w dzisiejszych grach czyli płynność nie precyzję. Ociężałość tych silników jest zbyt duża by zrealizować ten pomysł.

Pytanie do was drodzy koledzy po fachu, czy nie macie w swojej bibliotece małego silnika z wbudowaną fizyką i odtwarzaniem dźwięku, który pozwoli mi zapisać pewne dane klatka po klatce? Potrzebuje by ruch postaci ( dlugosc wcisniecia klawiszy itd, nie samo położenie ) mógł być precyzyjnie odegrany na innym komputerze. Nie może być tak że przycięcie komputera, spadek wydajnosci sprawi że duch będzie wskazywał inne położenie końcowe. W gre nie wchodzą teleporty postaci czy stałe jej przemieszczanie. Jeżeli na drugim komputerze postać napotka na przeszkodę to jej ostateczne położenie się zmieni.

W skrócie : chce „nagrywać” to co klika użytkownik

Wydaje mi się najprostszym rozwiązaniem wybór silnika małego co wyciągnie 60 kl/s i przy każdej klatce zapisze położenie postaci. Odtwarzanie jej w innym miejscu poprzez właśnie symulacje jej ruchu.

Może masz przypadkiem takiego gotowca?

Oferta finansowa:

  • 3 000-10 000 zł - zależnie od dostępnych funkcjonalności gry lub silnika
  • Przekazanie praw autorskich w ramach umowy o dzieło lub B2B.
  • 10% zysków generowanych przez sprzedaż gry

Wymagania

  • C#
  • obsługa Windows 10 lub mobile*
  • łatwość w dostępie do klawiszy i klików myszy
  • techniczna możliwość odtworzenia ruchu na podstawie zapisu eventów
  • obsługa 2D lub 2,5D
    • w przypadku mobile należy podać wymagania technologiczne by móc skorzystać z silnika. Głównie w przypadku mobile interesuje mnie Android.

Przy czym należy brać pod uwagę głównie kwotę, bo to czy gra zostanie wydana zależy od tego czy uda się osiągnąć zadawalającą precyzję ruchu postaci na innym komputerze. Wybiorę tylko jedną grę lub silnik, ponieważ jednego potrzebuje.

Propozycję swoich rozwiązań możecie przesłać w tym temacie ( postaram się regularnie wpadać przynajmniej raz w tygodniu ) lub poprzez mail : appgnawrot@gmail.com.

Piona,
Nawrot Marcin


#2

Cześć,

Chcesz robić loga z gry i potem replay? Czy może chodzi o synchronizację po sieci?


#3

Coś w rodzaju loga, po czym przeslać go sieciowo do drugiej osoby, której odtworzą się dokładnie ruchy postaci. Będzie ona musiala edytować mapę tak by postać dotarła do celu. Jeżeli nie zdąży to postać ma zrobic kolizje z mapa ale dalej odtwarzac swoje ruchy.

Nie będzie to tak wyglądać jak opiszę za chwilę, lecz pokazuje to dokładniej co potrzebuje.

Załóżmy że to gra typu labirynt. Obie strony maja mape ale rozni sie ta mapa kilkoma elementami. Pierwsza osoba przechodzi labirynt, po czym ta druga dostaje dokładne odtworzenie ruchow pierwszej osoby i musi odgadnąć jakie elementy labiryntu zostały u niej przestawione względem pierwszej osoby. Jak nie zdąży zmienić ściany to postać sie z nia zderza ale dalej odtwarza swoj ruch.

Gra jest bardziej skomplikowana w założeniach więc i precyzja ważniejsza.


#4

Czyli tak na prawdę rejestrujemy tylko zdarzenia z interfejsu (przyciski, akcje gracza) i odtwarzamy je (od razu lub z loga) na mapie rozgrywki gracza grającego oraz później na mapie innego gracza?

Lagów nie unikniesz, jak ci spadnie fps to spadnie i dokładność. Masz dwa środowiska działające z różną, nieznana wydajnością które dostają dokładnie ten sam input. Załóżmy, ze mapa świata na obydwu z nich jest taka sama, ale jeśli jedno z nich chodzi z mniejsza wydajnością to im dalej w czasie od punktu zerowego tym większa niedokładność. Pytanie o jakich jednostkach mówimy i jaka niedokładność jest dopuszczalna. Ile trwa cały proces. Jak by się zagłębić w temat (a kiedyś się zagłębiłem) to dojdziemy nawet do tego, że przeliczenia dla fizyki na różnych sprzętach dają różne rezultaty.

Jeśli nie chcesz tym obsługiwać sterowania prętami w elektrowni atomowej :slight_smile: i ma to być tylko jakiś labirynt o ograniczonej precyzji to takie coś był bym w stanie sieknąć nawet w unity. Własny silnik to strzelanie do wróbla z armaty.


#5

Oczywiście zgoda, że robienie silnika pod ten projekt jest niepotrzebnym wyzwaniem. Moje zapytanie głównie dotyczy odkupu już gotowych gierek lub silników z taką funkcjonalnością.

Odnosząc się do tego co napisałeś to jest pełna zgoda z tym, że takie logi są niezbyt odpowiadające rzeczywistym ruchom, gdy przychodzi moment przycięcia aplikacji. Nawet rozważaliśmy razem z teamem po prostu per klatkę coś wykonywać bezwzględnie od ilości FPS. Jednak to nie wyglądało dobrze.

Aktualne rozwiązania to głównie takie gdzie postacie maja okreslony punkt w danym czasie, ale to nie przejdzie. Potrzebuje odtwarzacza zdarzeń. Może jakiś mechanizm pozwalający zapisać pozycje i gdy następuje kolizja korekta wszystkich pozostałych pozycji, lecz to byłoby obciążające i być może trudne do objęcia fizyką gry.

Unity niestety probowaliśmy i on nie spełnia swojej roli.

Precyzja musi być co do 1-2px po 6 minutach odtwarzania. Probowalismy zapisywac chwile w ktorych wcisniety jest klawisz lecz to takze niezbyt dobrze sie odtwarzalo.

Problem jest dość złożony, stąd zapytanie o gotowe rozwiązania. Myślę, że jakbyś zaczął pracę w Unity to skończyłoby się jak u nas, tydzień napisanie prostego kodu na prostokatach i 3 miesiace walki o dobre odtwarzanie by sobie darować.

Problem z tych wyzwań trudniejszych, prawdopodobnie rozwiązywalny jedynie przez mix logow i polozenia


#6

Dlatego mówiłem, ze wszystko zalezy od oczekiwanej precyzji. Odtwarzanie przebiegu rozgrywki z logow robiłem, to nie jest trudne, jeśli ma służyć jako pogląd, gdy mamy poszczegolne punkty, w ktorych znajdzie się postać w danym momencie. Można by spróbowac innego podejscia - logowac akcje wprowadzoną przez input ale na innym poziomie abstrakci, np nie wcisinęcie i puszczenie kloawisza ‘ruch do przodu’ tylko poszzcegolne przesunięcia o dany wektor rozpoczynające sie w danej chwili gry. Na odtwarzanej rozgrywce postać próbuje sie przesuwać w danym czasie z dana predkością (co jest do wyliczenia z wektora) ale po napodkaniu przeszkody bedzie po prostu kroczyć w miejscu lub przesuwać się wzdłuz przeszkody, ale nadal usiłując iść w danym kierunku, powstrzymywana przez kolizję.


#7

Być może byłoby to dobre rozwiązanie lecz nauczony stratami dopóki nie mam dowodów na poprawne zachowanie w takiej sytuacji to nie odkupię takiego rozwiązania. Kilka programistów mówiło, że umie po czym odtworzenie ruchów dłuższych niż minuta kończyło się całkowicie innym położeniem postaci lub wypadaniem poza mapę.

Wszystko zależy od Ciebie czy będziesz chciał przygotować takie rozwiązanie i jego prezentację ( aplikacja ) bym mógł zweryfikować poprawność takiego działania.

Być może koledzy posiadają takie rozwiązanie, jeżeli chcesz spróbować to wyślij mi na mail bezpośrednio lub w PW jaką stawkę oczekujesz za gotowe rozwiązanie i możemy podpisać przedwstępne zainteresowanie takim rozwiązaniem.

Kwestia ze musi być wysoka precyzja i jeżeli już mamy rozmawiać o jakimś tworzonym rozwiązaniu to gra będzie platformowa, coś jak Mario Bros z NES, więc oczekiwałbym prezentacji już w takiej formie gdzie sprite skacze, rozpedza sie, staje na platformie itd. Wszystko moze byc biale na czarnym tle. Liczy się dla mnie sam gotowy mechanizm, który pozwoli na to działanie odtwarzania. Postać będzie mogła także strzelać z celowaniem myszką, wiec cel lecącego pocisku będzie znany ale kwestia tez by wyszedł on z aktualnego polozenia, nie wiem na ile Ci to skomplikuje.


#8

Ale ja absolutnie nie chcę tego zlecenia, zwyczajnie nie mam na nie czasu, mam teraz dwie gry na głowie, swoją i grę z pracy. Pisałeś, że masz ludzi, więc niech zbadają temat, bo coś mi mówi, ze to ma co najmniej szansę się udać. W wolnej chwili mogę ci parę rzeczy odpowiedzieć, jak okażą się pomocne to postawisz piwo.


#9

Rozumiem, ok przekaże chłopakom może się tym zajmą. W razie potrzeby będę się odzywał na PW


#10

a w czym tu problem. zapisujesz ruch gracz klatka po klatce a po zakończeniu gry wysyłasz wszystkie niezbędne informacje tcp i odtwarzasz, jedyny problem jaki tu widzę to różnice w fps na urządzeniu zapisującym i odtwarzającym, oraz totalny czas gry"" o ile aż tak ma być to dokładne… mimo wszystko początkowa pozycja i końcowa nie powinna sie różnić


#11

Niciel teoretycznie tak, praktycznie to się nie sprawdza


#12

A próbowaliście pobawić się w Unity z FixedUpdate i/lub Time.timeScale? Może to będzie właściwa droga?
https://docs.unity3d.com/ScriptReference/MonoBehaviour.FixedUpdate.html
https://docs.unity3d.com/ScriptReference/Time-timeScale.html

Jeśli nie ma parcia na klatki, to można dorzucić jeszcze to:
https://docs.unity3d.com/ScriptReference/Application-targetFrameRate.html

Sorry nie doczytałem, robiliście testy w Unity :smiley:


#13

GreGorn z tego co udało mi się ustalić z zespołem to zostało to wypróbowane i nie uzyskaliśmy zadowalającego efektu. Z tego co przejrzałem korespondencję z zespołem problem był z wpływem kolizji na ostateczny ruch przy odtwarzaniu. Nie wiem na ile to wytłumaczenie jest poprawne, lecz z pewnością efekt nie był zadawalający

Dziękuje za Twoje zainteresowanie i próbę pomocy :slight_smile:


#14

Bullet physics ma coś takiego jak CCD wtedy time step i dokładny offset klatki iteracji fizyki nie ma aż takiego znaczenia (brak tunnelingu)


#15

Devsh dzięki za podpowiedź, przekazałem i jest to sprawdzane przez zespół