Azért szó van ott az egész nap jutúbot nézegetõ munkatársakról is :p

Na igen, Mo-n szinte minden cég felsõ vezetése csak azon ügyködik, hogy minél jobban kisemmizzék az embereket

Nekem unokatestvéremmel fordult most elõ, hogy elment dolgozni, aztán egy hónap után pont a fizetés elõtt kirúgták a szemetek, egyszerûen parasztok ezek az emberek...

Idézet

---

Elf :
Egy újabb szomorú hír:
http://www.hardwired.hu/forum/forum.phtml?area=comment&id=25983

---

Itt meg érdemes elolvasni a kommenteket is.

Idézet

---

Ashkandi :
Ti kerestetek már rá magyar casual játékfejlesztõ cégekre? Eddig összesen talán hármat találtam, nem értem miért nem állnak össze az emberek 1-2 hónapos casual projectekre, kell valami cég a hivatalos részéhez aztán annyi, a többit csuklóból össze lehetne rakni.

---

Azt én se tom, de ha összeállnak, szóljanak má nekem is :p

Ti kerestetek már rá magyar casual játékfejlesztõ cégekre? Eddig összesen talán hármat találtam, nem értem miért nem állnak össze az emberek 1-2 hónapos casual projectekre, kell valami cég a hivatalos részéhez aztán annyi, a többit csuklóból össze lehetne rakni.

Egy újabb szomorú hír:
http://www.hardwired.hu/forum/forum.phtml?area=comment&id=25983

Azert mert ez multiplatfom kod. Es konzolon nagyon szar a branching, in order execution procikrol van szo. Jfben ne csal x86/x64 ben gondolkozzatok. Ezert van hogy altalanos kodban nagyon csunyan le vannak alazva a sokmagos sokghzs konzolprocik.

sirpalee

---

Branching (if/else/while/for/do) is avoided to the extent possible, especially mispredicted branches. See Appendix item 28.

---

A többit kb. értem, hogy miért szeretik / nem szeretik, de ezt nem. Az oké, hogy a teljesen lineáris kód jobban átlátható, na de könyörgöm, ciklusok és elágazások nélkül elég nehéz azért meglenni

Egy kis olvasnivaló, az EASTL-el kapcsolatban (az EA saját crossplatform ultra portable STL implementációja)

Game software issues

The discussion here involves gaming platforms currently developed for by EA. These include primarily console, hand-held, and desktop platforms. Virtually all game development within EA and other companies is done in C++; this isn't likely to change for many years. A number of characteristics distinguish game software requirements from desktop productivity software requirements. These include:

Game software always maximizes the hardware and is subject to Nathan's Laws.
Game source and binaries tend to be rather large. See Appendix item 5.
Game applications work with large amounts of application data. See Appendix item 5.
Console-based games run off of DVD drives, which are much slower than hard drives.
Game applications must execute very smoothly; there can't be unplanned execution pauses.
Non-desktop platforms don't have paged memory. If the application exhausts memory, it dies.
The lack of paged memory means that memory fragmentation can kill an application.
Non-desktop platforms have a fixed amount of memory, and it is smaller than desktop platforms. See Appendix item 27.
Non-desktop platforms have special kinds of memory, such as "physical memory," "non-local memory," "non-cacheable memory," etc.
Non-desktop platforms have processors and memory caches are less forgiving than those on desktops. See Appendix item 28.
Debug builds of game software need to be reasonably fast. See Appendix item 9.
Game platforms sometimes require the use of non-default memory alignment.

The above conditions lead to the following results:

No matter how powerful any game computer ever gets, it will never have any free memory or CPU cycles.
Game developers are very concerned about software performance and software development practices.
Game software often doesn't use conventional synchronous disk IO such as <stdio.h> or <fstream> but uses asynchronous IO.
Game applications cannot leak memory. If an application leaks even a small amount of memory, it eventually dies.
Every byte of allocated memory must be accounted for and trackable. This is partly to assist in leak detection but is also to enforce budgeting.
Game software rarely uses system-provided heaps but uses custom heaps instead. See Appendix item 26.
A lot of effort is expended in reducing memory fragmentation.
A lot of effort is expended in creating memory analysis tools and debugging heaps.
A lot of effort is expended in improving source and data build times.
Application code and libraries cannot be very slow in debug builds. See Appendix item 9.
Memory allocation of any type is avoided to the extent possible.
Operator new overrides (class and global) are the rule and not the exception.
Use of built-in global operator new is verboten, at least with shareable libraries.
Any memory a library allocates must be controllable by the user.
Game software must be savvy to non-default memory alignment requirements.
Memory pools are sometimes used in order to avoid fragmentation, even though they necessarily waste some memory themselves. See Appendix item 26.
Branching (if/else/while/for/do) is avoided to the extent possible, especially mispredicted branches. See Appendix item 28.
Virtual functions are avoided to the extent possible, especially in bottleneck code. See Appendix item 19.
Exception handling is usually disabled. See Appendix item 17.
RTTI is usually disabled or at least unused in shipping code.

Many of the above items are related to memory management and performance. As a result a lot of effort is put into optimizing the use of memory. Some games have been known to run with only a few KiB of system memory free. Some games run with no memory free at all and install an out-of-memory callback to free memory from elsewhere to satisfy the current request. See Appendix item 18. The memory fragmentation is not solved, as many of the analyses that have been used to measure memory fragmentation have largely applied to desktop software memory usage patterns, requirements, and environments. Game development has further memory constraints which make problems harder to solve. EA would like to welcome researchers to work with us on some of these problems, as they represent difficult problems that don't appear to be going away.

We also have the following practical considerations regarding C++ game programmers:

C++ isn't taught much any more in college. It's hard enough finding people who know C++, and harder finding people who understand templates of the kind you find in STL.
An increasing number of game developers are young and generic programming is foreign to them. Readers of this paper may have no trouble navigating a std STL header file, but this can be a daunting task for a less experienced programmer. An STL implementation that is very clear is worth more than experts may intially think.
Game developers (all developers, really) need to be able to examine and trace STL containers and algorithms. It's not a matter of debugging the containers themselves (which are already debugged) but a matter of debugging the user's use of the containers.
C++ templates are disliked by some because they are "tricky" and have "gotchas." You shouldn't have to be a language lawyer to use a programming language.

"A rendermoviekre gondolsz?" - lehet, hogy nem.

Idézet

---

Neossifter :
Ezekre lenék kiváncsi:
Hogy csinálják meg a mozgó képeket?

---

A rendermoviekre gondolsz? Hát, 3d-s programokkal úgy nagy általánosságban, pl. 3ds max, maya, xsi, blender. Persze ezen felül is elég sok programot használnak még (2d programok, kompozit, svn), de szerintem ha ennyire kezdõ vagy, akkor ezekkel még ne törõdj.

Idézet

---

Neossifter :
Hogy döntik el hogy mlyen játékokat csinálnak?

---

A klasszikus modell szerint demózgatnak sokat és házalnak a kiadóknál. Amelyikre azok rábólintanak, azt. Ha van megrendelés egy kiadótól, akkor meg olyat, amilyet azok akarnak. A kiadók meg általában a piaci trendek alapján döntenek.

Függetlenek, "kis" játékfejlesztõk ált. a shareware, iPhone stb. vonalon mozognak, ötletesebb játékmenetre helyezik a hangsúlyt.

Mennyire régirõl van szó? A DOS-os játékok kereskedelmi állapotának itt utána tudsz nézni, szerintem az abandonware játékok készítõi nem fognak megharagudni, de még talán a freeware-ek készítõi sem

Szerk.: látom nem Dos, csak sokáig nyitva maradt az oldal és nem láttam hogy írtad

Joga: konkrétan a régi Spektrumos játék feldolgozásáról van szó, a címe Chaos - The Battle of Wizards. Ha le van jogvédve, akkor átalakítok minden egységet benne, meg a szabályokat is egy kicsit, hogy ne legyen baj, de ha nincs lejogvédve akkor pofátlanul lemásolnám
Egyébként vannak valahol leírva erre vonatkozó irányelvek hogy mennyire kell másnak lennie egy játéknak ahhoz hogy ne gyanusíthassa meg senki a szerzõt? Gondolom ez már valahol itt biztos felvetõdött a JF.hu-n...

Idézet

---

Yokubo :
Nem tudja közületek esetleg valaki hogy régi játékoknál hol lehet utánanézni hogy a szerzõ milyen jogokat tart fenn? (Vagyis mennyire lehet lekoppintani az adott játékot )

---

Milyen játékot akarsz lekoppintani, és mennyire?

Ezekre lenék kiváncsi:

Hogy csinálják meg a mozgó képeket?
Hogy döntik el hogy mlyen játékokat csinálnak?

Nem tudja közületek esetleg valaki hogy régi játékoknál hol lehet utánanézni hogy a szerzõ milyen jogokat tart fenn? (Vagyis mennyire lehet lekoppintani az adott játékot )

Akik már régóta játszanak számítógépen, azoknak talán mond valamit a Graftgold név. Már régóta nem lehetett róluk hallani semmit. Hogy mi lett velük, mindenki elolvashatja a http://www.graftgold.com/ -on a History menüpontban. Nagyon érdekes szerintem.

Nem biztos, hogy ebbe a topikba tartozik, de az elõzõ linkhez kapcsolódóan:
Itt van pár történet a szoftverfejlesztés világából. Mind angol, nem tudom, hogy az elõzõhöz hasonlóak-e, meg nekem még nem volt idõm elolvasni egyiket sem, csak a könyvjelzõk között találtam a linket.
http://c2.com/cgi/wiki?SoftwareDevelopmentStories

Érdekes, de szomorú történet. Nem gondoltam volna, hogy a Stormregion ilyen utat járt be, mindig azt gondoltam, hogy az egyik legsikeresebb magyar JF csapat volt (bár a kiadott játékokat nézve lehet hogy az). Egyébként csak pár hónapja tûnt fel nekem, hogy már rég megszûntek.

kemény sztori...

Idézet

---

aaaa :
http://almainkutjan.freeweb.hu

---

Tetszett, hogy a történet személyközeli volt, szivesen olvastam volna többet a végérõl!

Csak a nagyobb garázsprojectek mindig MMORPG-k. Érdekes, hogy nincs nagyon olyan GP ami ésszerû határok között mozog, viszonylag rövid fejlesztési idõt igényel és "eladható". A komoly project mindig mmorpg a többi pedig packman, tetris, labirintus, etc.

Itt a logikusan kiválasztott cél tetszett ami tényleg megvalósítható és élvezetes, eladható játékot szül.

Szerintem nagyjából így zajlik ez ma is minden nagyobb garázsprojectnél, csak az internet megkönnyíti a kommunikációt - meg igazából szinte mindent, de talán a széthullást is meggyorsítja.

Nekem nagyon tetszett, hogy elég személyes volt az egész, mintha egy naplót, és nem egy leírást olvastam volna.. Ritkán találkozom ilyen szövegekkel, hogy -látszólag- tényleg minden gondolat leírásra kerül. Kicsit rövid volt szerintem, szívesen olvastam volna többet róluk - nem is gondoltam volna, hogy ilyen nehezen kezdték õk is - a kitartásuk viszont elképesztõ, éveken keresztül dolgozni, úgy, hogy gyakorlatilag mindenki semmibe veszi a munkájukat, és ennek ellenére akkor is be akarták fejezni, amit elkezdtek.. Becsülendõ az ilyen hozzáállás.

Nekem elsõsorban az jött le hogy megtörte a srácot az élet...
Azért érdemes volt elolvasni, látni hogy hogy is van ez a valóságban, vagyis volt lassan 10 éve, de eléggé szervezetlenül, teljesen a szerencsére bízva mentek neki, meg azt a sok tagcserét én már egy idõ után nem is tudtam követni... érzõdik hogy nagyon Magyar a történet...

Idézet

---

aaaa :
http://almainkutjan.freeweb.hu

---

Azért durva a történet...