Tegnap két extrém példán keresztül tudatosult bennem, hogy mennyire az önbizalomról szól a szakma. Nem csak arról, természetesen, de talán egy kicsit nagyobb a jelentősége, mint pl. a kézműves vagy szolgáltató iparban.
Az első példa: Van egy ismerősöm (igen, N, rólad írok) akinek a CV-jét javítgattuk tegnap. 7 éve dolgozik az IT supporton, olyan technológiákkal dolgozik, amiről én még nem is hallottam, és a CV ennek megfelelően elég meggyőző. Az önbizalma azonban nem üti meg azt a szintet, amit én természetesnek gondolnék ennyi tapasztalattal, így megragadt egy olyan állásban, ami nem díjazza megfelelően a képességeit.
A második példa: Olvastam egy cikket a Daily WTF-on, ahol egy szörnyű kódrészlet mellett ott szerepel ez a szöveg: ” those who knew better (i.e. management) sang plenty of praise, of both the PHP God, and his clean, well-commented code.”, azaz nyers fordításban: A vezetőség viszont egyaránt dícsérte a PHP Istent (a fent emlegetett kód alkotója) és annak tiszta, szépen kommentezett kódját.
Tehát, van egy hozzáértő de nem túl sikeres, és egy béna, de nagyra tartott szakmai dolgozó. Na, ez miért van így?
Képzeld el, hogy kijön a burkoló, újraburkolja a fürdőszobádat. Bemész és körülnézel, a csempék ferdék, a színek rondán vannak összeválogatva, és elfelejtett lyukat hagyni a szellőzőnek. Viszont a vizet nem ereszti át, tehát ebből a szempontból tökéletesen megfelel a követelményeknek.
Nyilvánvaló, hogy ezt nem hagynád annyiban, és meglenne a véleményed az illetőről. Viszont, képzeljük el, hogy vak vagy, és ugyanígy megnézed a dolgozó munkáját.. valamilyen módon meg tudsz győződni róla, hogy nem szivárog a víz (például úgy, hogy az alsó szomszéd nem jön fel), de azt már nem tudod megmondani, hogy rondák a színek, szóval örülsz, h kész a fürdőszoba és azt tudja, amit kell.
Ez az utóbbi a helyzet a szakmánkban. A vezetőség a legtöbb helyen nem ex informatikia dolgozókból áll, így max annyit tudnak megmondani a kódról, hogy “de szép színes betűk vannak benne”. Ők csak annyit néznek, hogy a weblap megjelenik, az adatbázisszerver működik, az appszerver kiszolgálja a kéréseket, azt már nem tudják igazából felmérni, hogy a táblázattal formázott, nem valid html mennyire nem karbantartható, nem tudják, hogy az adatbázisszervert nem meri senki három éve kikapcsolni, mert nem bíznak benne, hogy újra bekapcsolódik, sít. Itt jön az, hogy a barátságos, mindenre bólogató, gyorsan szállító programozót mindenki kedveli, a rendszergazdát, aki csendben végzi a dolgát, senki észre sem veszi, amíg valami el nem romlik, akkor pedig lekiabálják a haját..
Az Önbizalom Vására – a személyiség legalább annyit számít, mint a tudás.

A konstruktivitás világnapjának a jegyében nézzünk rá arra, hogy mi adhat nekünk okot az önbizalomra. A vezetőség elismerése? Nem, az nem szakmai elismerés. Nekem a következő dolgok adnak önbizalmat:
- Sokféle helyzetben voltam már, és még soha nem kellett feltennem a kezem, hogy: “Ezt nem lehet megoldani, és fogalmam sincs, hogy mit kellene most csinálnom”. Volt, hogy sokat szenvedtem a megoldással, de mindent sikerült megoldani vagy megkerülni.
- Tudom, hogy a szakma olyan széleskörű, hogy senki nem tudhat mindent, de ha bármire szükségem van, meg tudom tanulni, mert megvan a szakmai alapom hozzá.
- Kapok pozitív visszajelzéseket a munkámról olyan emberektől, akiket magamnál okosabbnak, szakmailag tapasztaltabbnak tartok.

Minden kollégámnak ajánlom az IT bármely területén, hogy nézzen magába néha, és gondolkozzon el, hogy helyén van-e az önértékelése? Akár csak a fenti három pontot és gondolja végig őket őszintén. Sokat lendítene a szakma színvonalán egy kis tisztánlátás..

Minap a Google Readerben alakult ki egy érdekes beszélgetés a kommentekben arról, hogy a Total Commander az most egy überjó tool, vagy egy szánalmas maradvány a DOS-os időkből. Nekem leginkább úgy tűnt (az első csoport tagjaként), hogy az utóbbi párt hívei nem ismerik a TC lehetőségeit. Ha azt nézzük, mi a jobb file másolásra mondjuk (amit többen felemlegettek), akkor nyilván személyes preferencia a dolog. Én nem elsősorban arra használom, igazából ha csak simán fájlt akarok másolni, akkor megnyomom a win-e kombinációt, és az így megnyitott explorerrel másolok drag&drop-pal.
Amire viszont használom, az már egy sokkal érdekesebb lista. Szerintem még tapasztalt TC felhasználók is találhatnak itt olyasmit, amit nem tudnak. (kommentben meg várom azt, ami egy értékes funkció, de én nem soroltam fel)

Megjelenítés: Meg a két tabos megjelenítés szerintem egy okos dolog. Kompakt, definiálja a munkafelületet, nem lesz tele a windowsunk egy rakás fölösleges ablakkal. Az “egy rakás” magyarázata: A TC tud tabos megjelenítést, azaz mindkét oldalon megnyithatunk több könyvtárat tabokon elhelyezve. Ezek a tabok kilépés-újra megnyitás után is megmaradnak. A két oldalt elválasztó oszlop elhúzható valamelyik oldalra, ha a másiknak több hangsúlyt szeretnénk adni, például nagyon hosszú fájlnevek megjelenítésénél. Mozgatás közben tooltipben meg is jelenik az aktuális elosztás mértéke, 100%-ban, jobb gombbal rákattintva pedig kapunk egy felugró menüt, ahogy beállíthatjuk a kívánt elosztás mértékét, pl. 50/50.

Fájl kiválasztások: A normális rákattintok és kiválasztom mellett a TC kínál más, hasznos kiválasztási lehetőségeket is. A szürke + megnyomásával tudunk select all-t csinálni, illetve ezzel tudunk olyat, h a *.jpg-t választjuk ki pl. A “*.zip;*.7z” formátummal többféle selectiont is megadhatunk. Természetesen az is működik, ha ezeket egymás után hajtjuk végre, illetve a név lehet mondjuk image* formátumú is. A szürke minusszal hasonló módon elvehetünk a kijelölésből, a szürke csillag invertálja a kijelölést, etc. Egészen más jellegű, de nagyon hasznos kijelölést csinál a shift-F2, azaz compare directories, ami a file-okat hasonlítja össze, és kijelöli mindkét oldalon azokat, amik vagy nem szerepelnek a másik oldalon, vagy más méretűek. A dátumot veszi alap ahhoz, hogy a változás esetén kitalálja, melyiket kell kijelölni. (Programozóként ez az utóbbi képessége nagyon hasznos!)
Kiválasztás kapcsán: Ha space-szel jelölünk ki egy könyvtárat, a TC kiszámolja a könyvtár méretét (lassssssan..) majd megjeleníti mellette. Ez hasznos lehet, amikor kíváncsiak vagyunk arra, hogy mi eszi meg a helyet a partíción. Annyival jobb talán, mint a windows hasonló funkciója, ami a könyvtár properties jobbgombos menüjében található, hogy látjuk a listában a méretet, és össze tudjuk hasonlítani egymással őket könnyedén.

Fájl másolás, mozgatás (F5, F6): Mint fent említettem, általában az explorert használom az 1xű, ad-hoc fájlműveletek végrehajtására. Van azonban egy olyan különleges képesség a TC-ben, ami miatt néha kifejezetten azt használom: a másolási queue. Amikor nagyon sok dolgot akarok átmásolni valahova, amik mondjuk jellemzően nem egy alkönyvtár tartalmai, vagy ilyesmi, akkor a másolást egy sorba rakom bele, ami gyakorlatilag sorban kerül feldolgozásra, aszerint, ahogy én hozzáadtam. Mivel a másolás nem párhuzamos, nincsenek problémáim az ide-oda ugráló winchester fejjel, fragmentált fájlokkal, etc. Ez a megoldás sokkal rugalmasabb, mint a kijelölés és másolás, mert gyakorlatilag a fájlrendszer bármely pontján dolgozhatok, nem kell egy könyvtárban maradnom a másolás végeztéig. Mellékesen megemlítem, hogy ilyeneket is tud a másoló/mozgató ablak, hogy ntfs jogosultságokat másoljon, szűrőket alkalmazzon (pl. csak egy típusú fájlt másoljon az összes kijelöltből), illetve beállítható, hogy hogyan reagáljon, ha mondjuk nem írható v olvasható egy fájl, system/hidden fájlok esetén, etc.

Új könyvtár létrehozása (F7): Ezt csak azért említem meg, mert sokkal kényelmesebbnek tartom az egy gombnyomásos könyvtár létrehozást, mint a sok kattintásost.

Helyben átnevezés (Shift-F6): Ez egy olyan feature, amit sokan nem ismernek. A windowsos megfelelője a két lassú kattintás a fájl nevén (azaz gyakorlatilag a kijelölöm majd még 1x rátakkintok a nevére, de ez nem duplakattintás); a lényege az, hogy ott helyben megjelenik egy editor, amivel át tudom nevezni a fájlt. Időnként hasznos. Edit: Többen rámutattak, h F2-vel ugyanezt kapod windowsban. Jó tudni!

Lister (F3): Egy nagyon hasznos, pehelysúlyú fájl megjelenítő. Nagyon gyors, emiatt ideális eszköz arra, hogy belenézzünk egy file tartalmába, amikor keresgélünk valamit. A tc saját oldaláról letölthetünk hozzá egy szintaxis kiemelőt is, ami szintén nagyon hasznos egy programozónak. Az egyik érdekessége, hogy alapból ismer pár hangfájl formátumot is, pl. mp3, így azokba is bele tudunk könnyen hallgatni, anélkül, hogy el kéne indítanunk mondjuk egy winampot (aminek aztán a playlistjét is szétvágja..) Van plugin a képfájlok hasonló kezelésére is.

Mélységi listázás (Ctrl-B): Amikor egy mély, bonyolult könyvtárszerkezet mélyén keresünk egy fájlt, vagy szeretnénk innen az összes .txt fájlt megnézni, jól jöhet a mélységi listázó tool. Ennek a lényege az, hogy az adott könyvtárból és annak összes alkönyvtárából (és azok összes alkönyvtárából, you get the picture..) kilistázza az összes fájlt egy egy mélységű listában, amit aztán átrendezhetünk, illetve úgyanúgy használhatunk, mint minden más könyvtárat. Ha egy fájlra állunk a kurzorral, és újra ctrl-b-t nyomunk, akkor visszaáll az eredeti megjelenítés, de odaugrik az adott fájlhoz, ami szintén hasznos lehet esetenként.

Fájl tartalom összehasonlítás: Ez egy vizuális, színes diff, ami megmutatja, hogy a két kijelölt fájl milyen módon tér el egymástól. Jellemzően szöveges fájlokra érdemes használni. Programozóknak külön hasznos, hogy a diff-en túl tud 2 way merge-öt is, ami egy nehezen feloldható SVN vagy CVS conflict esetén életet menthet.

FTP (Ctrl-F): Erre nem akarok túl sok szót vesztegetni, ftp kliens, ami a túloldalt is úgy jeleníti meg, mint egy könyvtárat, úgyhogy a másolás és hasonlók eléggé leegyszerűsödnek.

Csoportos átnevezés (Ctrl-M): Megint egy jól átgondolt és ügyesen megvalósított képesség, a csoportos átnevezés lehetőséget ad arra, hogy több fájl egyszerre átnevezzünk. Az eszköz ilyeneket tud, hogy az eredeti név kiegészítése vagy adott hosszra vágása, dátum, idő illetve egy konfigurálható számláló érték beillesztése a névbe, hasonló szépségek a kiterjesztéssel, keresés és kicserélés a névben, akár regexp alapon, kis-nagy betű megváltoztatása, és természetesen ezen beállítások elmentése/visszatöltése.

Letöltés URL-ről (Menü): A Commands menüben találhatjuk a Background Transfer Manager eszközt, ami a fent említett várakozó soros másolást/mozgatást is megoldja. Ennek egy extra képessége az, hogy képes egy url-ről letölteni a dolgokat, ami hasznos lehet, amikor egy valahol megosztott fájl listát szedünk le (de természetesen a html-t is leszedi gond nélkül, bár a hivatkozott fájlokat, mint a js meg css nem).

Fájl Szétvágás-Összeillesztés (Menü): Ha valamilyen okból szeretnénk szétvágni egy nagyobb file-t darabokra, (pl. mert túl nagy a nálunk lévő pendrive-hoz, vagy éppen adott méretű feltöltés engedélyezett egy weboldalra) akkor a Files menüben található Split File.. művelettel tehetjük ezt meg. Később az ugyanitt található Combine files segít nekünk összerakni újra. Ugyanitt vannak enkódoló és checksumot ellenőrző/generáló műveletek is. Ezeket én még soha nem használtam igazából..

Új fájl létrehozása (Shift-F4): Egy újabb egyszerű, kényelmi funkció. A fájl szerkesztése az F4 billentyű, ez azonban csak meglévő fájlokra alkalmazható (nyilván). A Shift-tel együtt használva létre is tud hozni új fájlt, ha olyan nevet adunk meg, ami még nem létezik. Ezután egyből meg is nyitja azt szöveges szerkesztésre.

Könyvtár megjegyzése (Ctrl-D, Add Current Dir): A fájlrendszerben mászkálva néha igényünk van rá, hogy egy másik pontra jussunk el gyorsan. Erre szolgál a könyvtár megjegyzése, amivel egy gyorslistába tudjuk elhelyezni az éppen látott könyvtárat. A Ctrl-D billentyűkombináció megjeleníti a már megjegyzett könyvtárak listáját, valami két műveletet: az aktuális könyvtár hozzáadását és a konfigurálást. Az új hozzáadásakor rákérdez a nevére, illetve arra is, hogy a célkönyvtárat (azaz a másik oldalon látható könyvtárat) is megjegyezze-e. Jelentősen fel tudja gyorsítani a navigációt olyankor, ha van néhány gyakran használt könyvtárunk.

Taszk automatizálás (Ctrl-D, Configure): A fenti gyorslista másik művelete a konfigurálás, ami egy sokkal ügyesebb tool, mint a legtöbben gondolnák. Egyrész, itt lehetőségünk nyílik arra, hogy a korábban felvett könyvtárakat átnevezzük, módosítsuk, vagy akár hierarchiába rendezzük, de ez nem minden. Alul láthatjuk a “Command” mezőben, hogy mi az a parancs, amit “kiad” a total commander, amikor kiválasztjuk ezt a megjegyzett könyvtárat. Ezt azonban szerkeszthetjük is, tetszőleges parancssori parancsot kiadhatunk vele, mint mondjuk “python”. Ez némiképpen korlátozott, mert sajnos nem veszi figyelembe a kijelölést, de néha hasznos lehet, amikor rendszeresen ismétlünk valami egyszerű taszkot, amit parancssorból lehet indítani. (pl. junit tesztek futtatása a projektre..)

Tömörített fájlok megnyitása (Ctrl-PgDn): Ha van egy zip fájlunk, sima enterrel kinyithatjuk, és innentől úgy fogjuk látni a TC-ben, mint egy könyvtárat a fájlrendszerben, amiben működnek a szokásos műveletek, mint másolás, törlés, etc. (ami természetesen ki-betömörítésként jelenik meg) A ctrl-pgdn annyival jobban működik, mint ez, hogy ha a zip fájl valamilyen más kiterjesztéssel jelenik meg (pl. jar, war, vagy éppen zap) akkor is bele tudunk menni, és nem a fájlrendszeri végrehajtással próbálkozik, mint a sima enternél.

Fájl (és tartalom) keresés (Alt-F7): Ez egy nagyon erős eszköz a hozzáértő kezekben. Mélységi keresés, amivel fájlnév vagy tartalom alapján kereshetünk fájlokat. Kezel Regexp alapú keresési feltételeket, tud keresni tömörített fájlokban is, konfigurálható a maximum mélység, a szöveg kis-nagybetű érzékenysége, encoding-ja, tudunk dátum, kor, méret, attribútumok alapján keresni, képes duplikált fájlokat megtalálni, valamint a kereséseket elmenteni későbbi használatra.
De ezzel még nem ér véget a képességek listája, ugyanis a találati lista maga is sok lehetőséget nyújt. Többek között, működik például a jobbgombos menü, meg tudjuk nyitni a fájlt gyorsnézetre, odaugorhatunk az adott fájlhoz, illetve a találati listát leküldhetjük a TC saját megjelenítő ablakába, ahol aztán ugyanúgy kezelhetjük őket, mint egy könyvtárat a fájlrendszerben: másolhatunk, törölhetünk, megnyithatunk, kijelölhetünk, ftp-zhetünk, etc.

Search As You Type (??): Az alapbeállítás talán alt-ctrl-type, én az alt-type-ot szoktam használni, de beállítható az is, hogy gépelésre automatikusan ez induljon el. Hasonlóan a mindenhol megszokott azonnali kereséshez, ahogy gépelünk, oda ugrik az adott keresésnek megfelelő fájl-hoz. A Ctrl-S billentyűkombinációval manuálisan is megnyithatjuk ezt a dialógust.

Parancssor (??): Nem emléxem, mi ennek az alapból bekonfigurált beállítása, én azt használom, hogy amit gépelek, az azonnal megjelenik a parancssorban. Az egyik leggyakrabban használt ilyen parancs a cmd, ami megnyit egy windows parancssori konzolt az adott könyvtárban, de gyakorlatilag úgy működik, mintha a windows run dialógusát (win-R) használnánk. Begépelés után ugyanúgy enterrel hajtjuk végre, mint amit a run-ba írunk.

Vágólap műveletek: Én nem használom, de esetenként hasznos lehet, ha az ember képes a kijelölt fájlok listáját kirakni a vágólapra, különböző extra információkkal, ld. alant:

ClientSide.java	1,661	05/06/2011 11:14	-a--
Orchestrator.java	478	05/04/2011 16:09	-a--
ServerSide.java	2,631	05/06/2011 11:10	-a--

Edit:Fájlnevek a parancssorba: Van pár billentyűkombináció, amivel a parancssorba tudjuk egyszerűen lemásolni a kijelölt fájlt: A Ctrl-J a nevét, a Ctrl-Shift-J a nevét és elérési útját másolja oda. (praktikus apróság: odarak egy space-t is, hogy ha parancssori paraméterként használod, azt ne kelljen kézzel beírni). Ha csak az elérési út kell, azaz az aktuális könyvtár, amiben állsz, akkor Ctrl-P.

Összefoglalva, mindenkinek ajánlom – még akkor is, ha azt gondolja, hogy a windows explorerrel minden egyszerűen megoldható – hogy töltse le a trial-t, és adjon neki egy kis időt. A fenti lista segíthet, hogy eligazodjon a felületen, és megtapasztalja a “pure awesomeness”-t, ami árad ebből a toolból. (Na jó, ezt csak azért mondtam, mert bírom a Kung-Fu Pandát )

Alapvetően két problémám van a DI-t és AOP-t megvalósító framework-ökkel: Hozzá kell adni egy extra jar-t a classpathhoz, amitől sokkal combosabb lesz az egész alkalmazás, és ha esetleg webstartozol, akkor még sign-olni is kell, valamint van egy performance hit – A DI a startupnál, az AOP pedig folyamatosan jelentkezik.
Vannak ugyanakkor olyan problémák, amit így lehet a legszebben megoldani, például a logolás elválasztása a függvényeinktől, vagy egy Chain of Command pattern esetén a Command osztályok inicializálása és a chain-be rakása.

A minap, amikor a javas Annotation-ökről olvastam, belefutottam az általam korábban még soha (tudatosan) nem használt apt (Annotation Processing Tool) nevű eszközbe. Ahogy olvasgattam a képességeiről, felmerült bennem, hogy ezzel meg lehetne oldani azt, amit én statikus DI-nak és statikus AOP-nek hívok.

Az apt lényege, hogy – főként az annotációkat használva, de generálisan is – fordítás előtt átszalad az egész kódon, és meghív bizonyos, a felhasználó által specifikált feldolgozó egységeket, amik átalakíthatják a kódot, vagy hozzáadhatnak új osztályokat, etc. Gyakorlatilag beteszünk egy extra lépést a kód elkészítése és lefordítása közé.
Valami ilyesmi a statikus AOP lényege: Bár kód szinten elszeparáljuk a különböző dolgokat, például a logolást, és pusztán egy annotationnel jelöljük, hogy ez a metódus kellene, hogy logoljon (@LoggingMethod, pl.), a lefordított osztályokban már megjelenik az a kód. Hasonlóan működik a DI is.

Például: Össze akarom gyűjteni az összes Command osztályt egy List -ba.
Csinálok két annotációt és egy statikus függvényt, mondjuk registerCommand(Command c). A függvény feladata mindössze annyi, hogy a fenti listába belerakja a Command osztályt (és csinál vele minden egyebet, amit csak akarunk), az annotációk pedig kb. így néznek ki:

@Target(ElementType.TYPE)
public @interface CollectionMarker {
    String collection();
    String enabled() default true; // erről meg ejtek pár szót
}

@Target(ElementType.METHOD)
public @interface CollectionMethod {
    String collection();
}

Az utóbbit elhelyezem a fenti függvényen, az előbbit pedig minden egyes Command osztályon, amit megírok.

Ezután a processzorok úgy működnek, hogy az egyik összegyűjt egy listát az összes CollectionMarkerrel megjelölt osztályról, a másik megjegyzi, hogy hol a CollectionMethod, majd a feldolgozás végén a megjegyzett osztályba berakunk egy static initializer blokkot, amibe belekerül egy csomó registerCommand(new AkarmilyenCommand());. S lőn, kész is van a chain.

Amit vesztünk ezzel, az
- A dinamikusság: Nem elég átírni egy XML-t és újraindítani az alkalmazást, mint a Spring-nél, ha változtatni akarunk valamit a dependencián. Mindenképpen újra kell fordítanunk az alkalmazást.
- Fordítási sebesség: A fordítás valamivel lassabb lesz
- Rugalmasság: Nyilvánvalóan van egy csomó olyan DI alkalmazás, amit nem lehet megoldani statikus módon.

Amit nyerünk vele:
- Némi performancia
- Átlátható kód extra frameworkok nélkül
- A Spring XML-hez viszonyítva: compile time ellenőrzés a dependenciákra
- Automatizált taszk végrehajtás (Az új command hozzáadása esetén csak az osztály kell létrehoznunk és ellátnunk a megfelelő annotációval, nem kell még különböző ponton beszúrni listákba)

Említettem fent, hogy az enabled attribútumról még ejtek pár szót: ha a gyűjtő egység figyeli ennek is az értékét, és nem gyűjti be azokat, ahol az enabled értéke false, akkor ennek a kapcsolónak az átbillentésével ki-be kapcsolhatjuk a gyűjtését. Akár még azt is megtehetjük, hogy a true-false helyett szinteket definiálunk, és bizonyos osztályokat csak debug módban használunk, productionben nem (ezeket, ha jól sejtem, akár ki is törölhetjük a feldolgozás során..).
Ez így magában még nem is annyira érdekes, de van még egy ennél is fontosabb szerepe: ha a fenti annotation definiciót (a Markert) megfejeljük egy @Inherited annotációval, akkor a leszármazottak is öröklik. Innentől elvileg minden leszármazottat begyűjtünk.. kivéve, ahol specifikusan kitesszük a markert a az enabled attribútum értékét false-ra állítva.

Akik az IDE integráció miatt aggódnak, azoknak sem kell igazából. Az Eclipse-t biztosan tudom, hogy támogatja ezt, a Netbeans és IDEA esetén pedig csak sejtem, hogy támogatják ezt a dolgot (vsz. 5 perc lenne kideríteni a google-lel).

Egyelőre csak a fejemben született meg ez a dolog, nem valósítottam meg, de a horizonton van. Ha lesz konkrétum, vsz kirakom valami elérhető helyre, mondjuk google code.

A Science fiction egyik visszatérő motívuma a nanobotok alkalmazása. Mi a lényeg: vannak egy a pici, szemmel láthatatlan méretű lények, amik molekuláris/sejt szinten képesek befolyásolni a környezetüket. Egy darab önmagában persze semmire sem elég, de képesek önmagukat sokszorosítani, és így a sok kicsi sokra megy elvet alkalmazva akár épületeket is fel tudnak építeni. Vagy éppen lebontani..

A technológiai problémákon túl (miniatürizálás, például) még van három nagyon fontos dolog, amit meg kell oldani hozzájuk:
- Nyersanyag: Építeni nem lehet a semmiből. Vagy anyag, vagy energia kell hozzá. És ez még nem is olyan 1xű, hogy hordjuk oda azokat az anyagokat, amik az adott építéshez kellenek (építés alatt értsük most ide a sejtek újraépítését is..) hiszen a nanobotok önsokszorozását is meg kell oldani valamiből. A mostani fizikai tudásunk szerint ez mind megoldható úgy, hogy az anyagot energiává, majd azt esetleg másféle anyaggá alakítjuk, de ez meg olyan problémákat vet fel, hogy maga az átalakítás is valószínűleg veszteséges lenne, ráadásul a fúziós folyamatok folyamán felszabaduló energiát valahogy kordában is kell tartani, mielőtt mássá alakítjuk. (képzeljük el, ahogy a nanobot javítja a fogunkat, és közben a felszabaduló hőtől elég a fejünk..) A dolog pozitív része persze az, hogy ha az anyagot át tudjuk alakítani, akkor tehetjük azt is, hogy az egész dolgot, amit fel akarunk építeni, először valami más, egyszerűen kezelhető anyagból építjük fel, majd amikor kész van, a megfelelő részeket olyan anyaggá alakítjuk ott helyben, amire szükség van.
- Energiaszükséglet: Munkavégzés akkor van, ha erre energiát használunk fel. A mozgatás, kommunikáció, a nanobotok működése mind energiát igényel. A fenti, anyagátalakításos technikával persze simán elhasználhatnánk abból az energiából is valamennyit, de nem biztos, hogy ez megoldható. Alternatív lehetőség a folyamatosan változó elektromágneses mező, amiből ki lehet nyerni az energiát ügyesen (tipikus példa a rádiótorony közelében megszólaló káposzta.. kis csúsztatással, persze). Egy – vagy több – ilyen generátort elhelyezve a környéken, a nanobotok energiához jutnának, anélkül, hogy az anyagot kellene azzá alakítani..
- Programozás, kommunikáció: Talán programozónak kell ahhoz lenni, hogy az ember megértse, mennyire nem egyszerű ez a probléma. Emergens viselkedést kell programozni, amivel a kis darabkák értelmes egésszé állnak össze, de van benne valami a fraktálokból is, ahogy a botok kialakítják és finomítják a formát, apróban és egyszerűben kezdve és eljutva a nagyig és bonyolultig. De ez még nem is elég, hiszen minden ilyennek az alapja az elhelyezkedés, azaz a botoknak (minden egyes darabnak) tisztában kell lenni a saját pozíciójával, mikromilliméter pontossággal. (na jó, a pontosság igazából a feladat jellegétől függ, felhőkarcolók esetén valószínűleg egy centiméteres pontosságú skála elég lenne, élő szervezet újraépítésénél viszont talán a mikromiliméter sem elég pontos..) Ha most gondolatban visszatérünk egy pillanatra a rezgő mágneses mezőt biztosító generátorainkhoz, akkor logikusnak tűnik az, hogy ezt a mágneses mezőt használhatjuk a lokáció kommunikálására is, akár úgy, hogy információt küldünk ki, akár úgy, hogy a generátorok frekvenciakülönbségéből és jelerősségéből számolja ki a bot, hogy hol van. Ha az első megoldást választjuk, akkor arra is van lehetőségünk, hogy konkrétabb inputot vigyünk a programozásba, pl. átbillentsük a botok állapotát valami másba.

Van amúgy ennek némi jelenlegi, kevésbé futurisztikus felhasználása. Képzeljük el azt, hogy egy anyag felszínét bevonjuk egy bizonyos pasztával, ami valójában mikroszkopikus gépecskékből áll – nem önsokszorosítók, és valójában nem is építeni tudnak, hanem valami mást. Például elfordulni.
Mire lenne ez jó? Például megoldható lenne, hogy olyan napelemet építsünk, ami mindig a lehető legnagyobb felületét fordítja a nap felé, ezáltal maximalizálva a felvett energiamennyiséget..

Kb. ennyit akartam csak leírni.

.. de azért leírom.

Szóval, mármár testközelbe kerültem azzal a problémával, hogy az mmo szerverben hogyan is ábrázoljuk a világot. A feladat: van egy rakás játékos a kis dolgaikkal, akik különböző cselekvésekkel befolyásolják az őket körülvevő világot, és azon töprengtem el, hogy ezt milyen módon lehet/érdemes nyilvántartani.
Az fő motívumok a következőek:
1. A játékosok közvetve és közvetlenül befolyásolják a világot
2. A játékosok kvázi real time látják, ahogy a többi játékos befolyásolja a világot
3. A világban vannak történések, amelyek nem játékos akció eredményei
4. Lehetnek olyan történések, amit az egymás környezetében álló játékosok másként érzékelnek. (példa lentebb, ha el nem felejtem)

Az egyik lehetséges modell a játékosközpontú. Ez gyakorlatilag arról szól, hogy a statikus világon felül minden játékosnál külön tároljuk az általa érzékelt szeletét a valóságnak, a cselekvései erre hatnak. Az elképzelhető előnye ennek a megoldásnak az, hogy ezek a világszeletek gyönyörűen elszeparálhatóak akár fizikai gépekre, de minimum virtuális gépekre, ami a cloud korában egyáltalán nem elhanyagolható. Azonban a második pont miatt – real time észlelése a többi játékosnak – ez csak akkor működhet, ha a játékosok közötti interakció ritka, hiszen minden, amit több játékos is lát, redundánsan jelenik meg, emiatt a kommunikáció exponenciálisan nő a közelben lévő játékosok számának növekedésével. Azzal lehet optimalizálni a dolgot, ha a csapatokat egy entitásként kezeljük, ám ezzel pont a legnagyobb előnytől esünk el – a könnyen lekezelt párhuzamos interakcióktól. Egy másik érdekes probléma a scope, azaz hogy a világ mekkora szeletét tároljuk el a játékosnak – ez megint a redundancia miatt érdekes.
Ez a modell egyébként különösen erős a negyedik pontban, azaz a relatívan érzékelt valóságokban, hiszen a relativitás itt nem transzformáció eredménye. (ld. lentebb) Emellett, egyedüli játékosnak sokkal gyorsabb lehet, mint a lent taglalt változatok.

A másik alapvető modell a terület/világközpontú. Ennek az a lényege, hogy egy világ/terület szintű adatstruktúránk van, ezen a modellen jönnek létre a változások, a játékos cselekvései és érzékelt világa egy transzformációval képeződik le. Az előnye nyilvánvaló: mivel minden egy helyen van nyilvántartva, nincs redundancia, ami tárolás szempontjából is előnyös, ráadásul sokkal kisebb az esély arra is, hogy valamilyen kommunikációs- vagy programhibából kifolyólag a duplikált adat elveszti a szinkronját.
Ámde bontsuk szét ezt is kétfélére: Szinkron és Aszinkron update. Az utóbbi az, amikor minden hatás azonnal érvényesül. Az előbbi az, amikor összegyűjtjük a cselekvéseket, és valamilyen időközönként lefut egy központi feldolgozó egység, amit a felgyűlt változásokat egyszerre ráilleszti a modellre, majd az így elkészült modell lesz az új alap.
Nyilvánvalóan ami az egyik problémája, az a másik előnye. A szikron változattal sokkal kisebb probléma a párhuzamos változtatás, ám – hacsak az update frekvencia nem nagyon magas – nem lesz olyan gyors a reagálás a változásokra. Az aszinkron változat adatforgalma nagyobb, hiszen minden változásról azonnal (realtime, ugye) értesül a játékos, legalábbis azokról, amik a környezetében történtek. Szerintem egyértelmű, hogy mik a különbségek.

Én jelenleg egy hibrid megoldáson gondolkozom. Az alap egy terület központú, több feldolgozó szállal dolgozó modell (pl. a környezet “maguktól” történő változásait egy sokkal ritkábban aktiválódó szállal kezelném, mint a harci cselekményeket) ugyanakkor teret hagynék a transzformátorokban egy privát content modulnak. Ezzel a megoldással tudnám kombinálni a fenti megoldások előnyeit, anélkül, hogy teljes mértékben fel kellene vállalnom a hátrányaikat.

Mondok egy példát: Két játékos lopakodik a sötét erdőben. Egyikük egy korábbi mágikus behatás miatt (vagy gombát evett..) hallucinál. Konkrétan, úgy tűnik neki, hogy a bokorból egy farkas ugrik elő és rátámad.
A helyzet egy kicsit problémás a hagyományos mmo-kban. Mit csinálunk a farkassal, hogy ne lássa a másik játékos? Mi történik a hullával, ha meghalt? Mi van a környéken lévő npc-kkel, akik ráaggrózhatnak a farkasra? Ha ezeket mind nem kezeljük le, akkor a játékosok beleszaladhatnak egy nagyon fura bugba..
Az persze nem opció, hogy az egész a játékos kliensén játszódjon, mert a szervernek tudnia kell erről, de a cheat programok miatt a játékos kliensében nem bízhatunk meg, hogy rendes update-et küld. Erre szolgálna a privát content modul, amit fent említettem, hogy a szerveren, de teljesen elkülönítve kezeli az eseményeket, anélkül, hogy saját instance-t kellene a játékosnak erre a hallucinációra létrehoznunk.

Majd meglátjuk, mi sül ki ebből.

Találós kérdés: Kit ábrázol ez a kép:
- Rámenős kofa
- Justicia
- Transszexuális Darth Vader

A helyes megfejtőket kedveljük.

Van egy rakás ismerősöm, akiknek amúgy tök jó sztorijaik lennének, de képtelenek szórakoztatóan elmesélni.
Pár jótanács azoknak, akik esetleg ilyen problémával küszködnek:
- Gondold végig előre: Mielőtt elmondod, gondold végig. Az egészet. Lehetőleg még azt is, hogy milyen szavakat használsz.
- Hagyd ki azokat a részleteket, amik nem számítanak, mert nem számítanak.
Példa: “És ott volt a Kati, őt nem ismered, a munkatársam kislánya.. vagy az unokahúga? nem, nem, a kislánya, biztos vagyok benne. Elég fiatal még. ”
Azon túl, hogy a hallgató számára valószínüleg teljesen lényegtelen az információ, hogy [ott volt;Katinak hívják;kislány v unokahúg;fiatal] zavaró is, mert megtöri az ívet. Különösen fontos, hogy ne kezdjünk el tanakodni egy oda nem illő információn.
- Legyen ív: a sztorit érdemes úgy mesélni, hogy egy ív mentén felépítesz egy elvárást, majd egy csattanó következik.
Példa: “Annyira sötét volt, hogy a legközelebbi fákat is alig láttam. Valahonnan balról motoszkálás hallatszott, majd egy roppanás, mintha valaki egy ágra lépett volna. Gyorsan odafordultam, és megpillantottam egy vörösen izzó szempárt..”
Ezzel felépítettük az ívet, most csapjuk le: “Na, ezt már nem bírtam idegekkel, inkább kiléptem a játékból”
A hallgató nem számít arra, hogy ez egy játék, így meglepi. Ez amúgy különösen a viccmesélésnél fontos.
- Fokozd a sebességet: A gyakorlott mesélők képesek arra, hogy megfelelően választott szavakkal, illetve ügyesen felépített mondatokkal szabályozzák az elbeszélés sebességét. Nem arról van szó, hogy egyre gyorsabban beszélünk, hanem arról, hogy először lassúságot érzékeltetünk, majd fokozatosan gyorsulást, és a sztori végén – lehetőleg egy hatásszünet után – hirtelen lecsap a csattanó.
Példa: “Lagymatag szellő fujdogált, lustán terelgetve a lehullott leveleket. Kupacokat épített, majd szétszedte őket, és aztán újra építeni kezdett.” – ez a lassú elbeszélés, hosszú, összetett mondatok, lassúságot érzékeltető szavak, mint “lagymatag, lustán”. Ismétlődés.
“Hirtelen csattanás hallatszik. Erős fény villan, és “BUMM”, felmorajlik az ég. Hangos reccsenéssel kidől egy fa.” Itt gyorsabb a tempó, erősebb hangok vannak benne (“csattanás”, “villan”), kiírom, hogy “hangos”. A mondatok rövidebbek.
Ez természetesen csak hosszabb történetek esetén jó.

Egy rakás ehhez hasonló dolog van (pl. a környezethűség, etc) amiket most nem akarok külön kiemelni. Akit érdekel, az olvassa el Umberto Eco “Hat séta a fikció erdejében” c. könyvét.

Van egy barátom. Szegény, nem százas, mindig evőeszközöknek képzeli magát.
Néha kiskanál. Néha villa, néha leveseskanál. Csak egy a fura: Sose kés ő.

Books and libraries have long held a position of esteem and regard within civilized societies. Books are the stoic, unchanging witnesses of our past; ghosts in our social conscience; memories of dreamers and the pale laughter from jestered spirits of discontent and revolutionary ideas. Books are the intimate lovers of readers everywhere, beguiling and beckoning travel to places and situations that open the mind and create a foundry of glowing, shiny alloys melded with the brittle iron of the present. Books have the power to lift us from poverty, shift our thinking and empower the powerless with knowledge. This, of course, is why they must be burned, banned and limited to only the privileged.

Source: ChristWire

(Bevezető megjegyzés: A bejegyzés nem minden része vonatkozik a sandbox MMO-kra, de jó pár pontban azokat is érintik a kommentjeim. Emellett elsősorban a fantasy mmo-kat tárgyalom, bár más mmo-kra is vonatkoztathatóak egyes megjegyzések)

A probléma
Lehetővé tenni a játékosok számára, hogy tárgyakat készítsenek, de:
- Ne legyen túl könnyű elkészíteni – Dolgozzon meg érte
- Ne legyen túl nehéz elkészíteni – Ne adják fel a próbálkozást
- Ne legyen túl egyszerű – Legyen némi befolyása arra, hogy mit készít
- Használható legyen – Összemérhető legyen a tárgy azokkal, ami a szörnyekből esik és az erőfeszítéssel, amit rá kell áldozni
- Ne legyen túl erős – Azért ne mindenki ebben/ezzel szaladgáljon, mert nincs értelmes alternatíva
A tipikus megoldás erre az, hogy a játékos alapanyagot gyűjt az erre szolgáló skilljével, ami ettől fejlődik, és előbb-utóbb képes lesz még jobb alapanyagot is gyűjteni. Az így megszerzett alapanyagból aztán a játékos tárgyakat készít, általában azt, ami a legkevesebb alapanyagból a legtöbb tárgykészítő skill fejlődést eredményezi, majd végül meglesz a skillje ahhoz a tárgyhoz, ami a szintjén tök jó, és akár 5 szinten keresztül is örül neki, amikor már túl gyenge lesz, és újra elölről.

Crafting mint küldetés, avagy hogyan működik
Képzeljük el a következő szituációt: Rag’rag, az ork sámán azt a küldetést adja nekünk, hogy szerezzünk neki 10 farkasbőrt és 30 farkasfogat. Cserébe csinál nekünk egy farkasfogakkal kivert farkasprém páncélt, ami a szintünkön teljesen jó. Elmegyünk, kiverünk 30 farkasfogat (pun intended), megnyúzunk 10 farkast, visszamegyünk, miénk a páncél. Rengeteg ilyen küldetés van. De akkor miért erőlködünk, hogy legyen craft a játékban, hiszen tulajdonképpen az ugyanerről szól? Három lényeges különbség van:
- A craftnál előre megszerezheted az összetevőket – akár másik játékostól is
- A craftnál van egy képzettséged, aminek elég fejlettnek kell lennie, hogy elkészíthesd a páncélt
- A küldetésből megszerzett jutalom általában hozzád van kötve, azaz másik játékosnak nem adhatod át/el.

A rendszer gyenge pontjai
- Az összetevőket tárolni kell, és ezeknek a száma hihetetlen méretűre tud duzzadni: pl. a wowban tierenként volt legalább 3-4 féle herb, meg még különféle halak és egyebek, amit az alkímiához tárolni kellett. A bankom 90%-át ezek foglalták el.
- Repetitív és időigényes: Tényleges használatba mondjuk minden általad elkészített századik tárgy kerül. A többit szétszeded (ahol lehet), vagy eladod a kereskedőnek. Azokban a játékokban, ahol egyszerű craft (receptre kattint és vár) van, ez azt jelenti, hogy 100x látod a zöld progressbart végigmenni. A bonyolultabb helyeken (ahol a craft egy minigame) ez azt jelenti, hogy százszor kell ugyanazt az kis minigame-et végigtolni, ami – lássuk be – ritkán annyira izgalmas.
- Nem realisztikus: Bár az az általános alapelvem, hogy a játéknak nem realisztikusnak, hanem élvezhetőnek kell lennie, ebben az esetben úgy gondolom, hogy a skála túlvégén vagyunk: ez a rendszer még rosszabb, mint a valóság. A tárgykészítés ne arról szóljon, hogy a legtürelmesebbek tudnak valami használhatót adni, hanem adjuk meg mindenkinek a lehetőséget, hogy – ha már rászánja az idejét arra, hogy megértse a rendszert, és kütyüzik vele kicsit – akkor legyen is érte valami jutalma.

Szerintem
Az elmúlt néhány bejegyzés után már talán nem meglepő, ha azt mondom, ezt is lehetne jobban csinálni Nem mondom, hogy az általam elképzelt az egyetlen üdvözítő megoldás, de az biztos, hogy sokkal élvezhetőbb lenne.
Lássuk alant, hogyan működne ez.

A mágikus tárgyak felépítése
Az egyik bajom a tárgykészítő rendszerekkel az, hogy nem gondolkoznak logikusan, akik kitalálják. Használjunk egy egyszerű struktúrát a tárgyak mágikus mivoltához:
- Mi a hatás: Ez a tömb írja le, hogy mit csinál a dolog, például hőt bocsát ki, fagyaszt vagy éppen gyógyít. Ide tartozik a hatás ideje is, ami lehet egyszeri (robbanás) vagy hosszabb hatóidejű, illetve akár permanens is.
- Kin jön létre a hatás: A felhasználó által kijelölt célponton? Valakin, akit megütünk a fegyverrel? Aki viseli a páncélt? Aki megüti a páncél viselőjét? Mindenkire, aki 5 méteren belül áll?
- Mi szolgáltatja a varázsenergiát?
Az első kettő eléggé adja magát. Megfelelő komponenseket használva, vagy egy listán rábökve megmondjuk, hogy “ezt tudja, és kész”.
A harmadik viszont egy olyan kérdés, amit érdemes kicsit tovább boncolgatni. Milyen forrásokról beszélhetünk egyáltalán?
- A felhasználó saját mágikus ereje: A felhasználó fogja a saját nyers mágikus energiáját, belenyomja a tárgyba, az meg megformázza és kisüti a megfelelő célpontra. MMO szempontból ez úgy jelenne meg, hogy levonunk a játékos manájából X-et, amikor kisüti a cuccot.
- A felhasználó életereje/egyéb erőforrásai: A nyers mágia forrása ebben az esetben egy átalakító, ami a mágiát valami másból állítja elő, például életerőből, vagy pénzből, vagy apró fehér kavicsokból.
- Magioaktiv anyagok: Olyan anyag, amiből folyamatosan áramlik a nyers mágia. Nyilván elég ritka, és nem is kifejezetten erős, de folyamatos, ezáltal lehetővé teszi a permanens hatásokat.
- Mágia akkumlátor: Egy mágikus energiával valamilyen metódus szerint feltölthető, annak a tárolására képes cucc. Érdemes elgondolkozni azon, hogy mi van, ha ez szivárog, azaz folyamatosan veszti el az energiát akkor is, ha nem használjuk.. érdekes taktikai vonatkozásai lennének.
- Elhasználódó forrás: Olyan forrás, aminek korlátozott töltete van, és ez szépen elhasználódik, és nem újul meg. Ez lehet egy lény bebörtönzött lelke (a’la Morrowind/Oblivion, bár ott permanens volt) de lehet például a varázsital főzéséhez használt varázsnövény ereje is. A lényege, hogy korlátozott használatot tesz lehetővé, és utána a tárgy nem fog működni, hacsak nem szedjük szét és cserélünk benne elemet.
- Megújuló erőforrás: Hasonló a magioaktív anyagokhoz, de képes lemerülni és újra töltődni. Gyakorlatilag úgy kell elképzelni, mint ha egy akkumlátort, ami mondjuk képes 10 egység tárolására, összekötnénk egy magioaktív maggal, ami 1 egységet termel percenként. Teljesen feltöltött állapotban képes 10 egység kibocsátására, de utána várnunk kell 10 percet, hogy újra használható legyen.

Tárgytervezés
A grindelés helyett tegyük a craft központi aktivitásává a tervezést. A játékos összeszed valami alapanyagot, és azokat felhasználva megtervezi a konkrét tárgyat, amit csinálni akar. Vegyünk példának egy fegyvert.
A játékos talál egy lehullott aszteroidát, ami közismerten mágikus fém. Van nála egy rubin, ami tökéletes befogadó eszköz tűzalapú varázslatokra. Ismer pár törpe rúnát is, amiket látott fegyvereken, és tudja, hogy ezeket bele lehet vésni a fegyverbe. Megnyitja a tervezőpanelt, az inventry-ból bedobálja a fémet meg a drágakövet, és a lore-ból bedobja a rúnákat.
A program megnézi, hogy ennyi fémmel milyen fegyvereket lehet gyártani. Kétkezes kardhoz, csatafejszéhez kevés, de lehet belőle csinálni egy hosszúkardot, vagy szablyát, vagy két tőrt, vagy 10 nyílhegyet (etc.). Ezeket felajánlja a játékosnak, aki – mivel csak egy darab rubin van nála – elsőre kiválasztja a hosszúkardot.
Középen megjelenik egy hosszúkard hozzávetőleges formája. A program jelzi, hogy kell még majd markolatot csinálnia, ami a megjelölt anyagokból nem fog menni, de hagyja, hogy tervezzen. Játékosunk kiválasztja a rubint, és megnézi, hova lehetne ezt elhelyezni. A program felajánlja neki, hogy beépítheti a markolat végére, a penge tövébe, illetve apró darabokra szétmetszve készíthet a pengére is drágakőberakást. Az elsővel a kard viselőjére tud hatást kifejteni, a második a pengét illetve a penge élét éri el, a harmadik esetben pedig a penge hegye lesz mágikusan biztosítva. Ezután a játékos a rúnákat is megvizsgálja, azokat csak a pengébe lehet belevésni, vagy az éléhez, vagy a vércsatornához, ami a vágásra/szúrásra hat megintcsak.
Rövidre fogva a szót, a játékos vizuálisan megtervezné a tárgyat, ami aztán a tervezésnek megfelelően működne. Például a fentiekkel lehet olyat csinálni, hogy a kard folyamatos tűzellenállást biztosít a játékosnak (a rubin), és emellé, amikor sikerül megszúrnia az ellenfelet, annak sokkal mélyebb lesz a sebe, mint a szúrás indokolná (sebzés rúna). Ami nagyon fontos eleme a dolognak, az az, hogy a játékos nem a recepthez gyűjt hozzávalókat, hanem az összegyűjtött alapanyagokat tudja felhasználni úgy, hogy azokból egy egyedi tárgyat készítsen.
Hogy nézne ez ki lebontva különböző tárgytípusokra:

Fegyverek, ékszerek, fémpáncélok
A fentiekben leírt módon tervezhetünk tárgyakat. Fontos, hogy a fegyver/ékszer szétbontható és a darabjai újra használhatóak, a páncél ezzel szemben leginkább csak beolvasztható.

Bőrpáncél
Képzeljük el, hogy a nyúzásból összeszedett, ilyen olyan formájú és minőségű darabokból dolgozunk. Ráadásul, az általunk használt mágia 1-2 bőrdarabra hat csak, szóval ha teljes varázspáncélt akarunk, akkor vagy sok mágikus komponenst, vagy egy darab, nagy, összefüggő bőrdarabot használunk – amit persze nem olyan egyszerű ügy megszerezni.
Ami itt szóba jöhet a bőrdarabokon kívül az a varráshoz használt cérna, ami lehet varázslatos, vagy sima is, a bőrre festett/belemetszett minták és a rávarrt fétisek, ezek mind befolyásolhatják a tárgy végső képességeit.

Ruhák
Hasonló a bőrpáncélokhoz, kivéve a bőröket. Itt is lehet különleges anyagokkal dolgozni, de itt sokkal nagyobb az esély, hogy egy egész ruhányihoz hozzájutunk.

Alkímia
Ebben rengeteg van, nem is írom le az egészet, csak címszavakban: Lehetséges hatókör: elfogyasztó személy, személy/tárgy, amire rákenték, vagy éppen bomba, ami egy területre ható azonnali vagy tartós hatást fejt ki – pl. méregfelhő. Számít, hogy mit kombinálunk és számít, hogy milyen alkímiai műveleteket hajtunk végre rajta (ez olyasmi, mint ami az ATP mudon volt..) de itt például simán bevezetném azt a rendszert, hogy vannak pl. napszakok, amikor ez/az a növény nagyobb potenciállal rendelkezik, és ha ilyenkor szedjük le, hatásosabb lesz. Esetleg lehet permanens hatású is némelyik potion – a növény, v ásvány, amiből készült, magioaktív – de ezek egy játékosra csak egyszer hatnak.

Fejlődés
Ha a tervezés van a központban, akkor hogyan fejlődik a tárgykészítő képesség? Erre alapvetően három féle megoldást tudok elképzelni:
- Sehogy. Nincs ilyen képzettség, a craft teljesen csak a designra épít, és a szintkorlátos hatásokra (ld. lentebb)
- Továbbra sincs ilyen képzettség, de vannak tierek. Ahhoz, hogy a következő tierbe léphessünk, mestervizsgázni kell az előzőből, azaz desingolni kell egy adott quality-vel rendelkező tárgyat, ha sikerül, továbbléptünk.
- A játékos kalandozó szintjét használjuk képzettség helyett.

Szintkorlátos hatások
Minden hatást szintfüggővé tennék, amit ezek adnak – gyakorlatilag bizonyos szintek között velünk fejlődne a páncél-fegyver-ékszer, amíg csak ki nem növünk belőle.

Elhasználódás
Minden kopna, használódna el, ahogy használjuk. A varázsfőzeteink elvesztik az erejüket, a páncélok elszakadnak, a fegyverek kicsorbulnak. Ez mind-mind munkát adnak a crafternek, hogy mindig legyen friss főzet (mert különben a rómaiak legyőzik a gallokat!), jól védjen a páncél és jól vágjon a kard.

Most jó lenne írni valami összefoglalást, de túl fáradt vagyok ehhez. A gondolatok nagy része szerintem átment így is.
Legközelebb talán arról fogok írni, hogy miért unalmas raidelni, és mit lehetne tenni ez ellen.