Pisanie gier a dekompilacja

Witam,
tak ostatnio się zastanawiam.
Piszę sobie gry od dłuższego czasu w C++. Nie skomplikowane 2D.
Ostatnio bawiłem sie XNA, wcześniej sporo programowałem w c# (ASP.NET, WPF).
No i pomyslałem że napiszę sobie grę w C#/XNA.
Ale kurczę jak sie dłużej zastanowiłem to wstrzymuje mnie to, że C#/.NET da sie bez najmniejszego problemu zdekompilować i podpatrzeć kod.
Tu oczywiście fantazjuję sobie ale gdybym np grę chciał sprzedać lub coś takiego to nie chciałbym że pierwszy lepszy mietek który sobie ściągnął jakiś DotPeek czy inne cudo , miał za free cały kod gry.

Czy ja tu brednie opowiadam czy jednak prawdę i da się jakoś przed tym ustrzec?

hasło na dziś: obfuskacja
zresztą - co Ci to przeszkadza?
weź na przykład taką grę "Terraria" - napisana w C#/XNA - zarobiła miliony dolarów, a kod każdy może sobie przejrzeć, wszystkie zasoby wyjąć - no i co z tego?

wiele narzędzi pomocniczych które niewątpliwie stworzysz przy robieniu gry pozwalających na jej modyfikowanie pozostanie zresztą tylko u ciebie
cała dokumentacja też
bez tego ciężko zrobić większy użytek z wyciągniętego kodu - zwłaszcza użytku nie zrobi "pierwszy lepszy mietek"

jeśli będziesz chciał żeby gra naprawdę się rozwinęła to z własnej woli udostępnisz API pozwalające na jej dowolne modyfikowanie
czyli nawet będziesz chciał zrobić więcej niż udostępnienie kodu gry

swoją drogą teraz popatrzałem na kod w/w gry i jakość kodu mnie nawet podniosła na duchu
oto jak jest na przykład zrobiona i18n:

http://pastebin.com/6Be2P5rV :O

jeśli jest jakiś kluczowy algorytm którym nie chciałbyś się dzielić, możesz go napisać w innym języku i wpakować do .dll

Postaw sobie inne pytanie: czy warto poświęcić czas na to, żeby "złamanie" gry utrudnić?

Zastanów się ile oni wydali na swoje zabezpieczenia.

unikalna_nazwa napisał(a):

zresztą - co Ci to przeszkadza?

W zasadzie to, że przez to wszystko jest jak OpenSource. A tego chcę uniknąć.

Open source jest open source, gdy licencja na to pozwala.

Jeżeli ktoś spiraci twoją grę to będziesz mógł dochodzić swoich praw jak każdy inny twórca.

Dekompilacja C# jest prosta, więc zarówno komuś będzie łatwo wykorzystać twój kod, jak i tobie będzie łatwo sprawdzić, że ktoś twój kod ukradł.

C++ też można zdekompilować i są zaawansowane narzędzia do tego, jak np Hex-Rays Decompiler: http://www.hex-rays.com/ W zasadzie zdekompilowany kod C++ powinien być podobny (tzn podobnie czytelny) do zdekompilowanego zaciemnionego (zobfuskowanego) kodu C#.

W zasadzie to, że przez to wszystko jest jak OpenSource. A tego chcę uniknąć.

OpenSource to nie jest, tak samo jak rzeczy na półce w sklepie nie są darmowe (nawet mimo że każdy może dotknąć i zobaczyć...).

Co tak koniecznie chcesz kryć w tym swoim projekcie?
Wstydzisz się swojego kodu? To wziąć książkę i czytać np. o wzorcach projektowych :P.
Masz jakieś tajne algorytmy? I tak nie dasz rady tego zabezpieczyć, myślisz że programy w C++ czy jakimkolwiek innym języku są same z siebie w jakiś sposób chronione przed tymi którzy wiedzą co robią? Nie, jeśli jakiś reverser będzie chciał się dowiedzieć co program robi to nie będzie miał z tym problemu. A script-kiddies i tak nie dadzą rady.
Nie chcesz innym podawać kodu na tacy? obfuskacja

unikalna_nazwa napisał(a):

http://pastebin.com/6Be2P5rV :O

Ciekawe dlaczego tak budują te stringi ;)

Ale przecież zdekompilowany kod wcale nie musi przypominać oryginału. Taki np kompilator Scali robi inlining na etapie kompilacji do bajtkodu.

Ciekawe dlaczego tak budują te stringi

Dobre pytanie...
Mam nadzieję że ten kod jest po prostu wygenerowany automatycznie z szablonu przez jakiś skrypt, wtedy by to całkiem sensownie wyglądało.
A string.Concat() (chociaż raczej wersja przyjmująca string[] a nie object[], ale...) to najszybszy sposób na łączenie n stringów.

Ale przecież zdekompilowany kod wcale nie musi przypominać oryginału. Taki np kompilator Scali robi inlining na etapie kompilacji do bajtkodu.

Niestety, C# tego nie robi - nawet Constant-Propagation jest robione runtime... Nikt w sumie nie wie czemu, można to tłumaczyć najwyżej oszczędnościami MS albo koncentrowaniem się na optymalizacjach JIT compilera.
Były nawet pomysły stworzenia programu (co najmniej dwa, w tym jeden ze strony społeczności Mono) który optymalizowałby kod IL, ale o ile wiem, nic na razie z tego nie wyszło.

@mfd: @Tezcatlipoca: akurat tę zamianę zrobił kompilator
możecie to sprawdzić samemu używając kodu z tego posta: http://stackoverflow.com/a/299541

ale w ogóle nie o to mi chodziło mówiąc o jakości tego kodu, tylko o hardkodowanie tłumaczeń i sposób w jaki jest to zrobione ;)