Gra pod Linuksa, płatna, ale open source.

[Savpether]

Witam, zamierzam stworzyć RPG pod Linuksa z moim zespołem, będziemy do tego używać silniku K2 engine, blendera i gimpa. Będzie sprzedawana drogą elektroniczną, na mojej stronie i w Ubuntu Software Center. Jednak moje pytanie jest innego rodzaju, ta gra ma być grą płatną, ale chciałbym by była w 99% otwarta i myślę, jak to zrealizować? To nie będzie MMO, więc nie będzie tam płatnych rzeczy. Kto ma jakieś pomysły? Chodzi o to, że jestem zwolennikiem wolnego oprogramowania, ale przychodzi taki czas, kiedy trzeba zacząć zarabiać i myślę sobie jak zarobić na tym, co wymyśliłem. W przyszłości zamierzam zrobić jeszcze parę gier i parę programów i jak uczynić je open i jednocześnie płatnymi? Bo pisanie zamkniętych aplikacji pod otwarty system łamie wszelkie zasady i moim zdaniem jest w stanie zniszczyć dany system, gdyż jest on bezpieczny właśnie dzięki otwartości, a gdy ujrzymy takie czasy, gdy to tylko system będzie otwarty, a reszta zamknięta, to chyba nie będzie za dobrze.
Pozdrawiam

[makson]

Żaden problem. Wydaj kod na GPL, a zastrzeżcie sobie prawa autorskie do grafiki i muzyki.
Tak między innymi wygląda:
Quaki
Aquaria
Revenge of the Titans
itp.

[Savpether]

Tak, ale jeśli kod ukaże się w internecie, to bez problemu geek go ściągnie, skompiluje na deb i rpm i wrzuci na torrenty.

[ethanak]

a to zamknietej binarki na torrenta wrzucic sie nie da?
jesli potrafisz zabezpiezyc zamkniety kod to i z otwartym sobie poradzisz (chocby jakas koniecznosc rejestracji, szczegolnie czyniaca malo atrakcyjnym korzystanie z kopii zarejestrowanej na kogos innego). poza tym pisales o 99% otwarcia - moze ten 1% jest rozwiazaniem?

[Savpether]

Tak ten jeden procent może być rozwiązaniem, jednak nie wiem jak zaimplementować system logowania tak, by po skompilowaniu reszty gra wciąż nie działała jak należy..

[anthrax]

A co powiesz na dystrybucję gry na licencji LGPL? Nie musisz bawić się w implementację zabezpieczeń, bo gra może mieć zamknięty kod. Po osiągnięciu zamierzonego zysku możecie udostępnić jej źródło na licencji GPL, zaś zachować sobie wszelkie prawa autorskie do grafiki, muzyki, filmów. Do stworzenia gry można wykorzystać m.in. biblioteki SDL.

[mat]

Witam, zamierzam stworzyć RPG pod Linuksa z moim zespołem, będziemy do tego używać silniku K2 engine, blendera i gimpa. Będzie sprzedawana drogą elektroniczną, na mojej stronie i w Ubuntu Software Center. Jednak moje pytanie jest innego rodzaju, ta gra ma być grą płatną, ale chciałbym by była w 99% otwarta i myślę, jak to zrealizować? To nie będzie MMO, więc nie będzie tam płatnych rzeczy. Kto ma jakieś pomysły? Chodzi o to, że jestem zwolennikiem wolnego oprogramowania, ale przychodzi taki czas, kiedy trzeba zacząć zarabiać i myślę sobie jak zarobić na tym, co wymyśliłem. W przyszłości zamierzam zrobić jeszcze parę gier i parę programów i jak uczynić je open i jednocześnie płatnymi? Bo pisanie zamkniętych aplikacji pod otwarty system łamie wszelkie zasady i moim zdaniem jest w stanie zniszczyć dany system, gdyż jest on bezpieczny właśnie dzięki otwartości, a gdy ujrzymy takie czasy, gdy to tylko system będzie otwarty, a reszta zamknięta, to chyba nie będzie za dobrze.
Pozdrawiam

Ciekawy pomysł. Przeważająca więkoszość firm udostepnia kod źródłowy danej gry po wielu latach, a więc w momencie, gdy nie chcą jej dalej rozwijać i nie uważam tego za złe rozwiązanie, ponieważ głownym celem jest zachowanie kompatybilności gry z nowszymi wersjami określonego systemu.Nie widzę niczego złego w pisaniu zamkniętych programów dla systemu open source i nie sądzę, aby firmy to czyniące łamaly jakieś zasady. W przeciwnym wypadku tworzenie aplikacji open source dla systemu Windows lub Mac OS X także naruszałoby jakieś dziwne zasady. Korzystanie z aplikacji oraz systemów open source także nie zapewni ci 100 % bezpieczeństwa. Jakoś cięzko mi sobie przypomnieć zamknięty program, ktory by doprowadził by do uszkodzenia danej dystrybucji Linuksa. Wiele osób korzystających z systemu Linux korzysta z zamkniętych aplikacji i cały czas czytam jakby to było fajnie, aby powstala jakaś komercyjna aplikacja dla Linuksa

[azhag]

Tak ten jeden procent może być rozwiązaniem, jednak nie wiem jak zaimplementować system logowania tak, by po skompilowaniu reszty gra wciąż nie działała jak należy..

Kompilatory to nie moja para kaloszy, ale czy nie daloby się podczas kompilacji dodać jakiś przełącznik? Przykladowo (pewnie palnę jakąś głupotę :)):

- w źródłach jest logowanie na serwer w stylu z jakimś haszem/kodem/czymkolwiek
- podczas kompilowania płatnej binarki ów hasz/kod/cokolwiek jest podawane i sewer poznaje tak logującą się binarkę
- podczas "darmowej" kompilacji ów hasz/kod/cokolwiek nie jest podawany (bo kompilujący go nie zna) i serwer może taką binarkę rozpoznać

Oczywiście tym bardziej nie wiem czy taki manewr jest stanie się oprzeć próbie rozgryzienia go. Hasz/kod/cokolwiek może być unikalny dla każdego klienta -- to pewnie ułatwi śledzenie nieautoryzowanych kopii, ale znacząco utrudni dystrybucję (każda sprzedana kopia to nowa kompilacji (przynajmniej binarki łączącej się z serwerem).

[ethanak]

teoretycznie:

Kod: Zaznacz cały

gcc -DUSERID=hash

gdzie hash to jakis odcisk z login/haslo na serwer (nie jakis prosty typu sha1 ale zrobiony wlasnym nieznanym nikomu algorytmem).
takie cos moze umozliwic zrobienie kompilatu demo ktory ma dostep do jakiejs ograniczonej wersji... tylko po co? jesli gra wymaga logowania sie na serwerze ktos moze opublikowac dane raz wykupionego konta.
ale jest to juz jakis pomysl. gra wymaga zalogowania sie i przekazuje serwerowi login haslo i hash...
to w przypadku kiedy serwer jest glupi i nie wie nic o uprawnionyxh uzytkownikach. jesli wie - nawet tego hasha nie trzeba, wystarczy uuid - nawet nie wkompilowany w program co otrzymywany przy zakupie.
ale to wszystko tylko przy zalozeniu, ze jakas czesc gry (witalna) siedzi na serwerze...

[Tomahawk]

gdzie hash to jakis odcisk z login/haslo na serwer (nie jakis prosty typu sha1 ale zrobiony wlasnym nieznanym nikomu algorytmem).

Zabezpieczenie przez zaciemnienie nie jest najlepszym pomysłem. Siłą nie ma być to, że nikt go nie zna. Bardzo łatwo stworzyć coś dziurawego. Lepiej wykorzystywać sprawdzone i bezpieczne metody.

Pozdrawiam

[ethanak]

Podaj przykład algorytmu, który:
a) jest ogólnie znany i sprawdzony
b) w sposób owszem znany i sprawdzony robi odcisk pary login/hasło
c) jest przesłany jawnie do serwera i służy do weryfikacji wprowadzonej pary login/hasło
d) nie pozwala na stworzenie własnej pary login/hasło przez osobę nieupoważnioną
I zauważ: nie jest to zabezpieczenie przez zaciemnienie, tylko odcisk zaszyfrowanej pary login/hasło (gdzie klucz szyfrowania jest znany wyłącznie producentowi i serwerowi).

[Tomahawk]

Możesz sobie generować własny zestaw loginów i haseł i trzymać ich odciski choćby w głupim shapierdziliard(lub inne tego typu) na serwerze. Delikwent wprowadza swój login i hasło, których odcisk jest przesyłany szyfrowanym tunelem na serwer i tam odbywa się weryfikacja.

Przykład wymyślony w locie. Pewnie dałoby się zrobić lepiej/ładniej.
Wymyślanie swojego odcisku, który potencjalnie jest banalny do złamania(i to w dwojaki sposób: błąd w kodzie lub błąd w założeniach) nie jest najlepszym pomysłem.

Pozdrawiam

[Savpether]

Ok, zespół jednogłośnie przegłosował otwartość kodu, zatem niech tak będzie. Gra będzie otwarta, dwadzieścia rozdziałów plus po moim zatwierdzeniu, będą mogły być wprowadzane kolejne, jako, że gra jest open source, każdy będzie mógł je napisać. Scenariusz już prawie skończony, ale nie będę się zagłębiał w szczegóły. Tomahawk ma rację, skorzystam z czegoś wypróbowanego, dziękuję wszystkim za dyskusję.

[ethanak]

@tomahawk:
chodzi o to aby nie trzymać loginów i haseł (ani ich odcisków) na serwerze... ja rozumiem że parę postów temu literówkę zrobiłem ale chyba nie aż tak straszną że nie zrozumiałeś zdania?
A algorytm generowania odcisku może być choćby zaszyfrowanie DSA login/haslo => sha1, gdzie klucz DSA znany jest producentowi i serwerowi.
Takie banalne do złamania? Spróbujesz?

[Tomahawk]

chodzi o to aby nie trzymać loginów i haseł (ani ich odcisków) na serwerze...

To co wg. ciebie powinno się trzymać na serwerze? Jak zweryfikować to co przyszło? o0
Odciski wydają się ok...

Po drugie:

(nie jakis prosty typu sha1 ale zrobiony wlasnym nieznanym nikomu algorytmem)

A algorytm generowania odcisku może być choćby zaszyfrowanie DSA login/haslo => sha1, gdzie klucz DSA znany jest producentowi i serwerowi.

WTF?! Własny nieznany DSA?

Takie banalne do złamania? Spróbujesz?

Jak będziesz sam implementował bez użycia żadnych gotowych bibliotek? Jakbym miał czas to można by się pobawić.

Są 2 ważne zasady dotyczące szyfrowań:
1. Nie wymyślaj nic swojego jeżeli nie masz naaaprawdę duuuuuuuużo czasu, żeby dokładnie się temu przyjrzeć. Wyjątek: jesteś niesamowitym geniuszem.
2. Korzystaj z gotowych PRZETESTOWANYCH bibliotek. To, że algorytm jest "niezłamywalny" nie znaczy, ze głupi błąd w kodzie nie zaprzepaści wszystkiego. Wyjątek: jesteś nieomylny.

Zdaje się było o tym(z przykładami) w książce: "19 Deadly Sins of Software Security: Programming Flaws and How to Fix Them"(jest też po polsku).

Polecam. Ciekawa lektura.

@Savpether
Pochwal się co tam tworzycie ;)

Pozdrawiam
edit://
Tak się kończy jak się miesza samemu: http://www.debian.org/security/2008/dsa-1571 :

Luciano Bello discovered that the random number generator in Debian's openssl package is predictable. This is caused by an incorrect Debian-specific change to the openssl package (CVE-2008-0166). As a result, cryptographic key material may be guessable.

[pioruns]

Cały ten wątek to przerost formy nad treścią. Czyli dyskutujemy i zabezpieczamy coś, co jeszcze nie istnieje. Mówię o tej "grze".

[Savpether]

Zawsze jeśli za cokolwiek się zabieram, muszę się solidnie przygotować na każdą ewentualność, nie lubię jak problemy wychodzą w trakcie, a myślę, że to forum od tego istnieje, by się zapytać i upewnić w danej kwestii, czy może jest inaczej?

[ethanak]

Takie banalne do złamania? Spróbujesz?

Jak będziesz sam implementował bez użycia żadnych gotowych bibliotek? Jakbym miał czas to można by się pobawić.

Ależ proszę.
Masz tu na początek kilka trójek login/hasło/odcisk

Kod: Zaznacz cały

Janek trSzafZH 76306a97cf9e93f117d24e6282075f4381640798
Tomahawk uowCgwvI c9a7786cd2703a23130516912ff6ef7907b58af1
Felek ggpRoRVW 8f0935ff3685359fc4f17b2006f4c326f8cfe4de
Irena xTxVrquf f7d30b0e37e8299816d792e1fd8162d4dfb5a89a
Ethanak NeLTypYy 1e04d63381a028313fd3d6ebc2128005882fb5db

Stwórz na tej podstawie nową trójkę.
Ewentualnie - ile jeszcze chcesz takich trójek?

[Tomahawk]

I jeszcze raz. Polecam poczytać dlaczego wymyślanie samemu(szczególnie implementacja) takich rzeczy jest nie najlepszym pomysłem. Poczytaj sobie w jak durnych miejscach błędy wychodzą i jakie wpadki można zaliczyć. Książkę Ci już poleciłem.

To, że mi tu wklejasz jakieś farmazony nic nie zmienia. Dodatkowo przypominam, że jak chcesz to weryfikować skoro nie chcesz trzymać ani loginu, ani hasła, ani hasha:

chodzi o to aby nie trzymać loginów i haseł (ani ich odcisków) na serwerze...

EOT z mojej strony

Zawsze jeśli za cokolwiek się zabieram, muszę się solidnie przygotować na każdą ewentualność, nie lubię jak problemy wychodzą w trakcie, a myślę, że to forum od tego istnieje, by się zapytać i upewnić w danej kwestii, czy może jest inaczej?

Jest tak jak mówisz ;P

Pozdrawiam