-

1.6.2011 18:12 | deleted | poslední úprava: 26.10.2021 01:13

-        

Komentáře

[w4rr10r]

Budu se držet Gluonu a Pygame.

[AsciiWolf]

Až s pomocí Gluonu a Pygame napíšeš nějakou 3D FPS/RTS/RPG, s grafikou a hratelností na úrovni minimálně toho Sauerbratenu, dej vědět.

[w4rr10r]

Zastávám názor, že 3D != zábava (leda u nějakých psychedelických šíleností nebo leteckého/automobilového simulátoru, když se to doplní fyzikou atp.), u RTS a RPG to akorát dělá zmatek. Osobně považuji téměř všechny FPS za zoufale nudné.

[kotyz]

Kromě Unreal Tournamentu

[w4rr10r]

Tak.

[AsciiWolf]

...Quake 3, Tremulous, OpenArena, UrbanTerror, ...?

[w4rr10r]

To už ani omylem. Bohužel jsem je zkoušel. Ztráta času. Prostě UT je UT.

[----]

quake 3 je perfektní, lepší než UT (to se nedá ale říct o OpenAreně) .. Urban Terror je taky dobrý. Ostatní moc nemusím. Spíš singleplayerovky jako half life ..

[kotyz]

To je všechno Q3 jak přes kopírák (a teď nemam namysli jenom to, že všechny běžej na ioquake engine)

[lukove]

vyzera to vynikajuco... mne na takychto 3d hrach chyba import (ak sa tovobec da) objektov napriklad vytvorenych v blenderovi

[----]

OF momentálně zvládá formáty modelů obj, md5, smd a iqm. .blend soubory podporovány nejspíš nebudou, nicméně z blenderu se dá třeba do toho iqm dost snadno exportovat.

[__dark__]

Pěkné, jak ten engine řeší písmo, bitmap font?

[----]

Momentálně bitmapy + varrays pro získávání podle koordinát, nicméně s novým GUI systémem také přijdou TTF fonty.

[lukove]

pocuj quarker nerozmyslal si nad spravenim virtualneho sveta v stylu SecondLife? v tomto by si nemal konkurenciu, samozrejme ak by to nebolo nad tvoje sily, lebo inac to bude zase len dalsia strielacka

[----]

Samozřejmě že to není "jen střílečka" --> můžeš v tom tvořit i RPGčka, i platformery, nejspíš i RTS třeba (s ovládáním kamery) .. v podstatě cokoliv. S příchodem online podpory se z toho stane celý "svět her", kde každý bude moct tvořit a distribuovat své hry a ostatní si je budou moct snadno z klienta stahovat a hrát. Mám i plány povolit na masterserveru komerční hry a jejich distribuci.

Jediný problém pro "open world" je formát map, a problém že nemůžeš mapy spojovat do "cells" a plynule mezi nimi přecházet - tzn. musely by se explicitně udělat přechody mezi mapami. Co se týče velkého počtu entit apod., později bude implementovaný scene manager, který bude vylepšovat efektivitu.

[AsciiWolf]

+1

[__dark__]

Ok, tom případě jdi přímo do freetype2, namísto SDL_ttf;)

[----]

už jsem s tím dělal nějaký testy, sdl_ttf stojí za ho*no, freetype2 je celkem low-level ale funguje vcelku dobře - udělal jsem si v opengl jednoduchou aplikaci na vykreslování a není to problém .. rozmýšlím se mezi vlastním algoritmem pro storage s freetype2 a ftgl - ono napsat pro herní engine pořádnou správu fontů s ttf není úplně jednoduchý, protože překreslování apod. není zrovna efektivní a je potřeba to nějak cachovat, aby se neztrácel výkon.

[__dark__]

Ono písmo je celkově komplikovaná věc. U nás je to jednoduché (1 char == 1 glyph), ale třeba arabština to má trochu komplikovanější, a je otázka, jestli takové jazyky chceš vůbec podporovat. Jestli jo, tak je tu SDL_Pango, ale je to další moře závislostí. Já to ve Fogu zatím neřeším, ale snažím se navrhnout API, aby to do budoucna bylo možné (text renderovat přes layout, který v budoucnu využije text-script).

[----]

jasně - no podpora pro třeba tu arabštinu nemusí být explicitní, ale bylo by dobrý, kdyby tam byl systém, který ty jazyky bude zvládat - v budoucnu. Samozřejmě samotný core engine nepotřebuje moc i18n/l10n, ale jednotlivý hry by to mohly potřebovat.

[Bilbo]

Arabština je navíc right-to-left (stejně jako třeba hebrejština) a pokud se míchá s latinkou tak je to celkem maglajs to pak dobře renderovat :). To už jsou skoro lepší čínský znaky, což je sice rozsypanej čaj, ale zobrazuje se aspoň normálně LTR a nemusí se jako u arabštiny spojovat.

[----]

no, to by se dalo řešit tyhle asijský a arabský písma přes fribidi.

[Petr Tomášek]

Hovadina. Pokud tomu nerozumíš, použij kompletní řešení; takže buď pango, nebo ICU. To řeší všechno prostě tomu dáš řetězec, ono ti to rozkouzkuje na kousky používající stejný jazyk; tyhle kousky uspořádá případně podle bi-di agoritmu; jednotlivé kousky přetransformuje (dost složitým způsobem) na seznam glyphů a jejich přesnou pozici. Pokud si to uděláš vlastní, tak tím budeš nasírat lidi, kteří by daný jazyk využili (znám to velmi dobře, např. OpenOffice dlouho používal vlastní udělátko, jen částečně postavené na ICU... jak mě to u některýh jazyků s*alo... dodnes je tam pár blbejch chyb...)

[robotics]

Čau, trochu offtopic, ale kdy budou balíčky e17 pro debian squeeze? Celou dobu sem se těšil až přejdu z lennyho abych měl zase Ečko a ono prd.

[robotics]

Jestli na to nemáš čas, tak mi dej přesnej postup jak to udělat a já budu dělat e17 balíčky pro debian 64bit. Ale musel by to být nějaký postup abych to pochopil .

[robotics]

Sice sem si ho podle nějakého návodu už doinstaloval, ale je to nějaké osekané, je tam málo modolů a je to tak nějak naprd.

[robotics]

Podle toho easy_17.sh skriptu nebo jak se jmenuje.

[----]

Nejspíš až pro E 1.0

[Honz]

Koukám, že lidské zdroje jsou, a né že né... Kdyby se toho chopili šikovní lidi a pokusili se udělat první linuxuvou hru (třeba střílečku, to je jedno) s příběhem stylu Half-life, to by byla bomba...

[Bilbo]

Tak zrovna vymyslet dobrý příběh je vcelku netriviální a v novějších hrách obvykle programátoři dělají menší část práce (jeden nebo 2 lidi dělají engine, ale dalších 5 až 10 dělá grafiku, zvuky, levely, mapy, vymýšlí příběh, dialogy, questy, atd ...). U větších týmů je lidí víc, ale poměr asi bude stejný :)

[Petr Tomášek]

Hele a nebylo by lepčí místo vlastního serveru použít telepathy-tubes?

[----]

Nemyslím si, snažím se omezovat závislosti a udělat kód co nejvíce přenositelný (později i např. na konzole); přidávání dalších závislostí je v tomto kontraproduktivní

[random]

Ale přidávat závislosti je mnohem lepší než přidávat kód. Pokud tedy existuje aplikace nebo knihovna, která dělá aspoň zhruba to, co chceš. V podstatě si tím rozšiřuješ vývojářskou základnu.

[----]

mluvím ne o potřebných závislostech, ale o redundantních závislostech. A správa klienta / serveru funguje naprosto bez problému i s ENet knihovnou, která je přiložena a je použita i v Sauerbratenu. Není třeba přidávat žádnou další závislost, prozatím.

[Petr Tomášek]

Jenže telepathy dělá něco jiného: ta umožňuje protunelovat streamy přes NAT kamkoliv - stačí, aby účastníci měli Jabber server... Vůbec pak není nějaký servery třeba řešit...

[----]

No, nemyslím, že prozatím něco takovýho potřebuju. Zvlášť když mám funkční systém.

[Petr Tomášek]

Ty to mozna nepotrebujes, ale uzivatele her by mozna ocenili, ze by nemuseli instalovat nejakej blbej server, chapes?

[----]

Ale vždyť oni nic instalovat nemusí. Klient i server jsou součástí enginu a oba mají funkce specifické pro engine. Pro každý build tak dostaneš dvě binárky.

[Petr Tomášek]

A jak se jako spojí, když jsou oba někde v p****i za NATem?

[----]

No, záměr je ten, aby uživatel žádný server ani nespouštěl; server je součástí, ale neměl by být vyžadovaný; servery poběží přímo u OctaForge a uživatelé se budou jenom připojovat jakožto klienti. Server je přiložen ze dvou důvodů - 1) někdo chce poskytovat vlastní servery pro uživatele; 2) pokud běží OF lokálně jakožto SP (v tom případě se použije server na localhostu). Až poběží master server a herní servery, tak de facto uživatelé vůbec serverovou binárku většinou potřebovat nebudou.

[Petr Tomášek]

No a proto říkám, že je daleko jednodušší postavit celou technologii na XMPP, protože tam už máš infrastrukturu hotovou a můžeš využít jak toho, že si uživatel může sám zvolit svůj server, tak taky server-server komunikaci...

[xxxxxxxxxxx]

kdyby jste radši programovali CAD. ))

[Dreit]

...v OctaForge