[hfall-list] Limbajul in care programam "caderea ciocanului"

mihai maruseac mmaruseacph2 at yahoo.com
Mon Nov 26 21:30:43 EET 2007


M-am gandit perioada asta si am ajuns la o intrebare: "Ce limbaj de programare vom folosi ca sa facem jocul?"

Dupa o perioada lunga de cugetare am ajuns la urmatoarele aspecte:

1.Ne trebuie neaparat un limbaj de programare in care sa putem lucra pe clase.
Astfel avem variantele C++, Java sau C#. Tinand cont ca Java = C# din majoritatea aspectelor putem elimina Java mai ales ca C# devine tot mai popular si ca putini vor sa-si instaleze masina virtuala Java dar mediul .NET se instaleaza de cat mai multi oameni. Avem .NET si pe Linux deci nu putem spune ca a folosi C# e ceva not open source: DotGNU (http://www.gnu.org/projects/dotgnu/) sau Mono(http://www.mono-project.com/Main_Page).

2.Ne trebuie un limbaj care sa permita scrierea de cod modular si usor de documentat. Aici cred ca facilitatea /// a C#-ului este foarte utila (daca functioneaza si in Mono sau DotGNU) pentru ca permite generarea documentitei foarte rapid si real-time uneori. Plus ca in C# nu trebuie sa ne batem capul cu de-alocarea pointerilor si modul cum ii folosim pentru ca se poate lucra in C# fara a-i utiliza.

3.Nu as vrea sa ne complicam cu cate doua fisiere pentru acelasi obiect. Ma refer aici la organizarea fisierelor clasa din C++: .h si .cpp. In C# totul e simplu, in acelasi fisier sunt si declaratii si cod.

4.In C++ cu OpenGL s-au mai scris jocuri, lumea evolueaza si se va ajunge in curand la C#. Hai sa incepem si noi cu ceva nou.

Cam atat am avut de spus despre limbajul in care vom programa engine-ul si main-frame-ul jocului. Haskell nu stiu inca (daca exista vreo sugestie pentru asa ceva), C++ pare depasit desi e instrumentul de dezvoltare folosit traditional. Si pentru C# exista totusi dezavantaje:

1.Daca vom scrie in C# numai cei care vor avea .NET, Mono sau DotGNU vor putea rula jocul. Cred ca aici nu e o problema din moment ce Vista chiar vine cu .NET preinstalat (daca stiu bine)

2.C# nu genereaza cod direct ci cod intermediar care e usor de spart. Va trebui sa lucram putin si in codul intermediar ca sa blocam orice reverse engineering (daca va fi nevoie). Daca e nevoie de asa ceva, e mult mai usor de lucrat in cod intermediar decat in asembly.

3.Cu C# cam nu ne putem atinge de asembly.

4.Exista zvonuri potrivita carora C# e mai putin performant ca timp de executie. Am teta asta recent cu urmatorul program simplu: am generat in 3 cicluri for numere pana la 100000, le-am inmultit si apoi am folosit cate o rutina sa le descompuna in factori primi si sa calculeze radacina patrata a numarului utilizand metoda newton. Diferenta intre C# si standard C++ (not managed) a fost (in windows) de mai putin de 0,1% in favoarea lui C#. 
Nu stiu de ce dar C++-ul a ramas in urma pe acest test.

Deci, eu as prefera C#.

Un alt aspect care va veni mai tarziu dar trebuie luat acum in seama este acesta: vom avea nevoie si de un fel de exteriorizare a codului ca sa putem face profiling sau sa dezvoltam mai multe module de AI. Aici va trebui sa folosim Python sau Lua dar nici unul din ele nu are inca exemple in C#. La chestia cu exemplele nici cartile de game design sau opengl nu au exemple in C#. Daca ramanem pe C# va trebui sa le portam. Eu totusi prefer un mic overhead cauzat de portare decat zile si nopti pierdute cautand o eroare mica din cauza unui pointer neinitializat cum trebuie.

Concluzia: Prefer C# dar daca doriti altceva nu-i nici o problema. Cat nu se ajunge la Fortran sau altele mai vechi accept orice. Voi invata si Haskell daca vreti sa programati in asta.




      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rosedu.org/pipermail/hfall-dev/attachments/20071126/e145ca93/attachment.html 


More information about the hfall-dev mailing list