Zobrazit předchozí téma :: Zobrazit následující téma |
Autor |
Zpráva |
Mihulik
Založen: 18. 07. 2008 Příspěvky: 22
|
Zaslal: 18. červenec 2008, 16:19:24 Předmět: Vývoj herního enginu |
|
|
Ahoj,
nemáte někdo prosím nějaké zajímavé materiály k tvorbě vlastního enginu?
Vlastním doma knižky Vývoj her v jazyce Java a Programování dokonalých her v Javě. V těchto knižka je sice popsaná samotná implementace, ale nějaký obecný návrh, jak navrhnout funkční engine, jsem z nich nedostal:-(
Samotný engine by měl být:
2D a 2,5D(izometrický pohled), objektově orientovaný, snadno modifikovatelný a podpora rozšíření (modulární).
Takovou bych měl zhruba představu, rád bych se do ní pustil, jenže nějak nevím, jak začít, jelikož mi chybí obecná návrh toho enginu. Nějaký "engine" jsem si již zkusil napsat, jenže nesplňuje výše uvedené věci. Prakticky se ukázalo, že se jedná jen o jednoúčelový engine schopný pracovat s hrou, která na něj byl napsaná, ale v případě, že bych ho chtěl využít jinak, znamenalo by to přespání 90% kódu.
Budu rád za každý uvedený materiál.
Ještě jedna věc by mě zajímala-návrh editorů pro engine. Právě uživatelsky/vývojářsky přístupné enginové nástroje/editory podle mě dělají dobrý engin enginem. Bohužel v těchto knihách o tom nic není a na internetu jsem taky nic slušného nenašel (přiznávám ovšem, že ohledně vývoje enginových nástrojů jsem zatím příliš nehledal...)
No, doufám že z příspěvku je patrné o co se snažím a co hledám, takže děkuji za případnou pomoc.
Na internetu se samozřejmě dá najít řada článků, jenže mně se zatím nepodařilo najít nic, co se by se zabývalo samotným návrhem enginu (analýzou a navrhnutím projektu) |
|
Návrat nahoru |
|
 |
VladR
Založen: 30. 07. 2007 Příspěvky: 1322 Bydliště: Greater New York City Area
|
Zaslal: 18. červenec 2008, 19:44:01 Předmět: |
|
|
Uz len tym, ako rozlisujes medzi 2D a 2.5D ti vznikne uplne iny engine, kedze to je ako miesat hrusky s kapustami. Oba enginy mozu vyuzit nejaky spolocny zaklad na funkcionalitu ako Input, Sound, Particle Manager, Texture Manager,HUD, ale AI a renderer budu o dost ine, kedze tie sa musia nasit na mieru hry. Uplne vseobecnu AI nenapises, ani to nema zmysel, kedze primarnym cielom dobre napisaneho kodu na AI je predovsetkym debugovatelnost a prehladnost, a nie nejaka zbytocna abstraktna vseobecnost. Teoreticky vies zvolit 2 zanre, kde by AI pre 2D aj 2.5D bola rovnaka, ale to nie je dolezite.
Nejake zakladne objekty pre rendering budu spolocne, ale celkovo to bude o dost ine, o optimalizacii ani nehovoriac, lebo ta je specificka pre kazdu hru.
A mimochodom, http://scientificninja.com/advice/write-games-not-engines |
|
Návrat nahoru |
|
 |
Vilem Otte

Založen: 18. 09. 2007 Příspěvky: 462 Bydliště: Znojmo - Sedlesovice, Kravi Hora
|
Zaslal: 19. červenec 2008, 01:07:30 Předmět: |
|
|
Jak psal VladR - write games not engines.
Mimochodem programování enginu je mnohem těžší než programování hry, sám teď dělám na jednom enginu (vlastním) - http://www.otte.cz/engine/index.php. Výrazně nedoporučuji psát vlastní engine - i když sám jsem do toho šel (není to ostatně můj první větší projekt).
Dělám na tom ještě s jedním člověkem (kdysi byli 2 další), a navrhovat funkční engine je docela o hlavu. Nejprve je potřeba vědět co bude engine podporovat, tvůj popis je velice strohý a celkem k ničemu při navrhování. Obecně jde o věci -
Jaký typ vykreslení - 2D/2.5D je sice pěkné, ale hodláš použít nějakou knihovnu, nebo psát úplně od začátku?
Jaké operační systémy hodláš podporovat - Windows, Linux, ... ?
Programovací jazyk a jeho stupeň - ASM (no to asi ne), C (tj. funkcionálně), C++ (objektově), C# (aspektově), nebo jiný?
Design - Objektový (často bývá singleton), Plug-in architektura, Funkcionální?
Podpora networkingu - Peer to peer, Client server, ... ?
SDK - plánuješ nějaké editory (uff psát cross-platform editory aby byly rychlé a vykreslovaly stejně jako "ve hře" je docela o hubu, i dneska)
Zvuk a hudba - 2D zvuk, 3D zvuk, streamovaná hudba?
Fyzika (i pro 2D hry se musí napsat) - detekce kolizi, dynamika pevnych teles, mekkych teles, obleceni, kapaliny (mno, spis jen ta detekce kolizi ve 2D)
AI - skriptovana, pathfinding, neuronove site (nedoporucuji, je s tim hodne prace ... i kdyz vysledky stoji za to), decision based, ... ?
Co se tyce grafiky a knihovny ... planujes psat vlastni (je to zkusenost, ale vetsinou neprakticka pro jednoho cloveka ... sam jsem delal nejakou dobu na ForgottenLibu, nekde tady jeste bude postnuty screen z nej, ano slo o real time (spis interactive) ray tracing na dnesnich x-jadernych masinach s vysledky blizicimi se fotorealismu, stale na nem delam - ale je to docela dost prace). Jestli planujes vlastni - co planujes podporovat, ve 2D me napada dynamicke osvetleni, stiny, jaky typ texturingu (napr. i bump mapping jde ve 2D!)
Management sceny s grafikou - jaky typ optimalizace, mno nejaky Quad-tree bych tipoval pro 2D jako nejlepsi.
Jake maji byt schopnosti te knihovny?
A nakonec popis enginu - coz je opravdu hnusna prace (ale nekdo ji udelat musi, a nikdo ji za tebe neudela).
Takze jestli chces pomoct s navrhem enginu - odpovez na ne a ja se pokusim pomoct s navrhem.
Prepsani 90% kodu hrozi velmi casto i v pripade klasickeho enginu a jenom vylepseni vykreslovaní (např. s mým enginem jsem implementoval real time ray tracing na dosažení vyšší kvality vykreslení - hybridním renderingem a přepisoval jsem 90% dosavadního kódu (pravda nějaký ten měsíc to už bude)). _________________ Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. |
|
Návrat nahoru |
|
 |
VladR
Založen: 30. 07. 2007 Příspěvky: 1322 Bydliště: Greater New York City Area
|
Zaslal: 19. červenec 2008, 08:06:25 Předmět: |
|
|
Ako pise Vilem, refactoringu sa nevyhnes. Nikdy nebudes vnutorne spokojny s tym, ako je dana komponenta napisana, vzdy to pojde napisat krajsie, cistejsie, abstraktnejsie, lepsie zoptimalizovane.
Ja som momentalne na stvrtom refactoringu terrain rendereru. Tym myslim uplne zahodenie daneho kodu a novy design s novymi poziadavkami - vzdy po sfunkcneni aktualnych poziadaviek sa ti zrazu vynoria 2-3 dalsie. Uz teraz vidim 4 dalsie nove poziadavky, ktore by znamenali znacny refactoring
Je to uz cele krasne navrhnute, automatizovane, v podstate len davam hi-level prikazy subkomponentam ako sa maju spravat a oni si to uz medzi sebou same vyriesia
Takisto, zabudni na to, ze pokial za sebou nemas zopar hier a iteracii enginov, ze napises nejaky vseobecnejsi. To pride az casom, az za sebou tie pokusy budes mat a budes presne vediet ze co treba. |
|
Návrat nahoru |
|
 |
quas4
Založen: 18. 10. 2007 Příspěvky: 199
|
Zaslal: 19. červenec 2008, 09:40:14 Předmět: |
|
|
Vilem Otte napsal: |
SDK - plánuješ nějaké editory (uff psát cross-platform editory aby byly rychlé a vykreslovaly stejně jako "ve hře" je docela o hubu, i dneska) |
Nesouhlasim. Jako reseni mam nad enginem python bindings. Pomoci pythonu lze elegantne psat v qt/gtk - oba maji user interface designer. Vse je rychle a "vykreslovani" je prakticky stejne rychle jako ve hre. To vse samozrejme za predpokladu ze samotny engine je multiplatformni. |
|
Návrat nahoru |
|
 |
Mihulik
Založen: 18. 07. 2008 Příspěvky: 22
|
Zaslal: 19. červenec 2008, 12:23:34 Předmět: |
|
|
Uf, děkuji za reakce, takže postupně:
citace: |
Uz len tym, ako rozlisujes medzi 2D a 2.5D ti vznikne uplne iny engine, kedze to je ako miesat hrusky s kapustami. Oba enginy mozu vyuzit nejaky spolocny zaklad na funkcionalitu ako Input, Sound, Particle Manager, Texture Manager,HUD, ale AI a renderer budu o dost ine, kedze tie sa musia nasit na mieru hry. Uplne vseobecnu AI nenapises, ani to nema zmysel, kedze primarnym cielom dobre napisaneho kodu na AI je predovsetkym debugovatelnost a prehladnost, a nie nejaka zbytocna abstraktna vseobecnost. Teoreticky vies zvolit 2 zanre, kde by AI pre 2D aj 2.5D bola rovnaka, ale to nie je dolezite.
Nejake zakladne objekty pre rendering budu spolocne, ale celkovo to bude o dost ine, o optimalizacii ani nehovoriac, lebo ta je specificka pre kazdu hru.
A mimochodom, http://scientificninja.com/advice/write-games-not-engines |
je pravda, že s tím 2D/2.5D jsem trochu přestřelil. Bude se to muset rozhodně udělat tak, jak zhruba píšeš-společný základ, ale spousta věcí již rozdílná.
Jinak článek jsem si právě vytiskl a jdu si ho přečíst do vany , ale engine mi připadá jako mnohem větší výzva, než samotná hra. Ovšem nervů to bude stát taky mnhoem víc, to je pravda
citace: |
Mimochodem programování enginu je mnohem těžší než programování hry, sám teď dělám na jednom enginu (vlastním) - http://www.otte.cz/engine/index.php. Výrazně nedoporučuji psát vlastní engine - i když sám jsem do toho šel (není to ostatně můj první větší projekt).
Dělám na tom ještě s jedním člověkem (kdysi byli 2 další), a navrhovat funkční engine je docela o hlavu. Nejprve je potřeba vědět co bude engine podporovat, tvůj popis je velice strohý a celkem k ničemu při navrhování. Obecně jde o věci -
Jaký typ vykreslení - 2D/2.5D je sice pěkné, ale hodláš použít nějakou knihovnu, nebo psát úplně od začátku?
Jaké operační systémy hodláš podporovat - Windows, Linux, ... ?
Programovací jazyk a jeho stupeň - ASM (no to asi ne), C (tj. funkcionálně), C++ (objektově), C# (aspektově), nebo jiný?
Design - Objektový (často bývá singleton), Plug-in architektura, Funkcionální?
Podpora networkingu - Peer to peer, Client server, ... ?
SDK - plánuješ nějaké editory (uff psát cross-platform editory aby byly rychlé a vykreslovaly stejně jako "ve hře" je docela o hubu, i dneska)
Zvuk a hudba - 2D zvuk, 3D zvuk, streamovaná hudba?
Fyzika (i pro 2D hry se musí napsat) - detekce kolizi, dynamika pevnych teles, mekkych teles, obleceni, kapaliny (mno, spis jen ta detekce kolizi ve 2D)
AI - skriptovana, pathfinding, neuronove site (nedoporucuji, je s tim hodne prace ... i kdyz vysledky stoji za to), decision based, ... ?
Co se tyce grafiky a knihovny ... planujes psat vlastni (je to zkusenost, ale vetsinou neprakticka pro jednoho cloveka ... sam jsem delal nejakou dobu na ForgottenLibu, nekde tady jeste bude postnuty screen z nej, ano slo o real time (spis interactive) ray tracing na dnesnich x-jadernych masinach s vysledky blizicimi se fotorealismu, stale na nem delam - ale je to docela dost prace). Jestli planujes vlastni - co planujes podporovat, ve 2D me napada dynamicke osvetleni, stiny, jaky typ texturingu (napr. i bump mapping jde ve 2D!)
Management sceny s grafikou - jaky typ optimalizace, mno nejaky Quad-tree bych tipoval pro 2D jako nejlepsi.
Jake maji byt schopnosti te knihovny?
A nakonec popis enginu - coz je opravdu hnusna prace (ale nekdo ji udelat musi, a nikdo ji za tebe neudela).
Takze jestli chces pomoct s navrhem enginu - odpovez na ne a ja se pokusim pomoct s navrhem.
Prepsani 90% kodu hrozi velmi casto i v pripade klasickeho enginu a jenom vylepseni vykreslovaní (např. s mým enginem jsem implementoval real time ray tracing na dosažení vyšší kvality vykreslení - hybridním renderingem a přepisoval jsem 90% dosavadního kódu (pravda nějaký ten měsíc to už bude)). |
Za popis se omlouvám, takže k jednotlivým bodům:
-engine má být nezávislý na OS
-psaný v Javě, tzn. objektově
-grafickou knihovnu hodlám využít jen Java 2D, která je platformově nezávislá a dá se s ní dělat docela hezké věci. Případné další knihovny, který bych využíval, by museli být opět platformově nezávislé
-design má být objektový, snadno rozšiřitelný=podpora plug-in, přístupný k vývoji (souvisí to s podporou editorů a kvalitní dokumentací)
-síťová podpora by samozřejmě měla být, ale ne v prních verzí...časem ovšem doplnit podporu jak P2P, tak Client-server
-podpora editorů (editor map(dláždicové mapy), editor textů,...)
-2D zvuk se zvukovými efekty, přehrávání hudby
-ve 2D asi opravdu jen ty detekce kolizí, co se týče fyziky.
-AI-podpora jak jednoduché skriptované, tak složitější decision based, samozřejmě hledání cest, podpora evoluce (učení se AI)
-žádnou grafickou (ani zvukovou či jinou) psát nehodlám, ale využít již hotové Java2D
Engine by měl být tedy určen k využití u 2D her, měl by být udělaný tak, aby v něm šlo napsat v podstatě jakýkoliv žánr her. Engine by měl být platformově nezávislý (Java a platformově nezávislé knihovny případně). Engine by měl být objektově navrhnutý. Samotné části enginu by měli být co nejméně na sobě závislé, aby nebyl pro uživatele enginu problém případné nevyhovující části jen upravit pomocí vhodnější náhrady. S tím souvisí snadná rozšiřitelnost a modifikovatelnost enginu. Engine by měl být kvalitně dokumentován (to už je samozřejmě ale jen moje starost). Engine by měl být jednoduchý a bezpečný na použití (i za cenu menšího výkon, z důvodů právě řady kontrol).
citace: |
Ako pise Vilem, refactoringu sa nevyhnes. Nikdy nebudes vnutorne spokojny s tym, ako je dana komponenta napisana, vzdy to pojde napisat krajsie, cistejsie, abstraktnejsie, lepsie zoptimalizovane.
Ja som momentalne na stvrtom refactoringu terrain rendereru. Tym myslim uplne zahodenie daneho kodu a novy design s novymi poziadavkami - vzdy po sfunkcneni aktualnych poziadaviek sa ti zrazu vynoria 2-3 dalsie. Uz teraz vidim 4 dalsie nove poziadavky, ktore by znamenali znacny refactoring
Je to uz cele krasne navrhnute, automatizovane, v podstate len davam hi-level prikazy subkomponentam ako sa maju spravat a oni si to uz medzi sebou same vyriesia
Takisto, zabudni na to, ze pokial za sebou nemas zopar hier a iteracii enginov, ze napises nejaky vseobecnejsi. To pride az casom, az za sebou tie pokusy budes mat a budes presne vediet ze co treba. |
To že můj první engine nebude zázrak je jasný, ale chci právě proto co nejvíc vymakat úvodní návrh, abych se právě tomuto refactoringu 90% kódu při každé změně vyhnul  |
|
Návrat nahoru |
|
 |
nou

Založen: 28. 07. 2007 Příspěvky: 1050
|
Zaslal: 19. červenec 2008, 14:03:52 Předmět: |
|
|
robit refraktoring 90% kodu kvoly optimalizacii je myslim v poriadku. ale robit refaktorin 90% kodu kvoly pridaniu jednej dvoch funkcii nasvedcuje na chybu v navrhu alebo nepripravenost kodu na taketo rozsirovanie. _________________ Najjednoduchšie chyby sa najtažšie hľadajú. |
|
Návrat nahoru |
|
 |
VladR
Založen: 30. 07. 2007 Příspěvky: 1322 Bydliště: Greater New York City Area
|
Zaslal: 19. červenec 2008, 15:12:49 Předmět: |
|
|
Alebo to skor znamena, ze vyzvy boli naplnene a je treba sa vydat k novym vyzvam, ktore s povodnym navrhom po funkcnej/vizualnej stranke vela spolocneho nemaju. |
|
Návrat nahoru |
|
 |
MD

Založen: 29. 07. 2007 Příspěvky: 437 Bydliště: Praha
|
Zaslal: 19. červenec 2008, 15:55:55 Předmět: |
|
|
Ja mam otazku: Kolik programatoru a kolik casu (v rokach ) si do toho muzes dovolit investovat? A stihnes to driv, nez zalozis rodinu / zacnes pracovat?
Takze moje rady:
1) Dobre odhadni, co zvladnes a kolik ti to zabere casu.
2) Mej dobrou specifikaci a jasny cil.
3) Vyber si jednu vec a tu udelaj dobre (At mas neco, kde budes vynikat nad ostatnimi enginy)
4) Cokoli nepotrebujes, vyskrtej, podivej se po uz hotovych komponentach
5) Seznam se s konkurenci. Hlavne Game Maker
K tomu patri i muj engine KRKAL - stale neni dokonceny tak, jak bych chtel aby byl. Doporucuju se kouknout, jak tam delame editor levelu a skriptovani. Vice zde: http://www.ceske-hry.cz/forum/viewtopic.php?t=1011 a zde: www.krkal.org
Krome GM se doporucuju kouknout i na Torque (meli tam 2d verzi), Mnemonicuv WME a spoustu dalsiho..
PS: A vubec, proc zacinat z necim novym? Nechces mi radeji pomoct a pustit se do Krkala (Jen to nedelam v Jave a prenositelnost jsem momentalne obetoval) _________________ - play with objects - www.krkal.org - |
|
Návrat nahoru |
|
 |
Mihulik
Založen: 18. 07. 2008 Příspěvky: 22
|
Zaslal: 19. červenec 2008, 16:31:43 Předmět: |
|
|
Tak ze začátku budu na projektu pracovat bohužel sám.Čas si právě z těchto důvodů, co píšeš raději netroufnu odhadnout
Na tvůj KRKAL jsem koukal, opravdu zajímavé. Sice jsem ho ještě nestáhl, ale dle obrázků a textů to vypadá opravdu zajímavě, takže se na to zcela určitě chystám
K tvému projektu bych se rád připojil, bohužel pokud se nepletu, tak je psaný v C++ a stím bych ti bohužel absolutně nepomohl (sice mi časem nezbyde nic jiného, než se i na to C++ podívat, ale v současnosti se mu zatím vyhýbám)  |
|
Návrat nahoru |
|
 |
Vilem Otte

Založen: 18. 09. 2007 Příspěvky: 462 Bydliště: Znojmo - Sedlesovice, Kravi Hora
|
Zaslal: 19. červenec 2008, 19:12:36 Předmět: |
|
|
#VladR - Psaní obecného enginu není sranda ani když za sebou máš již nějaký ten hotový. Zrovna dělám na svém co nejobecnějším a i tak to dá dost práce vše organizovat do rozumné (a rychlé) struktury.
#quas4 - Mno mě jde hlavně o to, že ve hrách máš většinou pohled z 1. resp. 3. osoby a já dělám editor s pohledem dynamickým (především nad terénem pro přehlednost), a dynamicky osvětlovat modely o několika milionech polygonů desítkami dynamických světel s PCML variance shadow mapami (omnidirectional, spot a directional) je docela problém, když k tomu započítáš dynamické reflekce na desítkách objektů a dynamickou radiositu (updatovanou téměř instantně) pomocí ray tracingu tak při pohledu zezhora už můžeš mít nějaký ten problém.
Ve hře můžu šetřit na optimalizaci (nebudu ji tady teď popisovat - jakou provádím, protože by to skoro znamenalo tady psát knihu)
#Mihulik - Dobře, takže engine má být nezávislý na OS => psát budeš zřejmě pod SDL. V javě jsem osobně nedělal, ale můj engine je taky postaven v C++ (ale funkcionálně! Takže je to víceméně čisté C ... objekty jsou pomalé (mnohem pomalejší než funkce, tedy pokud je nenapíšete jako prasata), ale dobře se s nima pracuje). Ale pro první engine bych objekty rozhodně doporučil. Java2D jako knihovna - nedělal jsem, ale zkus zvážit i použití OpenGL (pro 2D grafiku se dá velmi slušně použít) - a je hardwarové.
Plug-in způsob je rozhodně jeden z nejlepších (ovšem pluginy samotné si nesmí odporovat). Co se tyce ostatniho - AI, veř, že psaní AI ti zabere mnohem více času, než počítáš. Jinak evoluce je základ učení, pokud ale chceš opravdu nejdokonalejší AI - tak můžeš zkusit neural networks (ale do začátků moc nedoporučuji).
Kvalitní dokumentace, hm... dokumentace je ta nejpěknější a nejhorší práce jaká může být - většinou jsi rád, že už to máš za sebou ... ale píšeš ji velmi často hodně dlouho pokud jsi sám (mám na mysli i ukázkové demonstrace k tomu).
Co se týče designu, osobně bych ti doporučoval Singleton (asi jsem se již zmínil). Nebude to nejrychlejší řešení, ale funkcionálně by jsi v tom měl asi docela bordel (nemůžu však jistě soudit, protože nevím jak jsi zvyklý psát).
Každopádně strukturovat se to snaž takto:
Hlavní-----------Grafická část--------Samotné volání JAVA 2D (popř. OpenGL)
|
|----------Fyzikální část--------Funkce fyziky
|
|----------Zvuková část--------Funkce zvuku
|
|----------Networking čast------Funkce Networkingu
Ty funkce můžeš zaměnit a místo nich napsat rovnou objekty, budeš li chtít. Co je podstatné je ten 2. sloupec, roztřiď si kód takto do částí, aby jsi ho měl přehledný a dobře se ti poté vše dokumentovalo.
Nevím jestli tady někdo jiný má zkušenosti s OOP, a jestli používá jinou architekturu. Já sám jsem si až moc přivykl na funkcionální a tím způsobem, že část kódu mám v C (výjmečně v C++) a velké části v ASM (většinou SIMD SSE řada příkazů ... hlavně teda můj ForgottenLib, tam jde o každý kousek rychlosti a v tom mi pomáhá SSE ASM).
#nou - Kvoly prekopani povodneho rasterizeru (OpenGL kniznice) na hybridny rendering znamena prekopat vacsinu OpenGL kodu.
#MD - Hm... ja zase muzu říct, pojďte mi všichni pomoct na mém enginu - ale když na něm dělá více lidí každý s jiným způsobem psaní, tak s organizací jsou trochu problémy (a někdy také s dokumentací výsledného kódu, ale neříkám že se to nedá ).
#Mihulik - C++ se časem moc vyhnout nedá, a já jen doporučuji se naučit, programuje se v něm dobře a přece také:
"Kolik jazyků znáš, tolikrát jsi robotem" _________________ Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. |
|
Návrat nahoru |
|
 |
MD

Založen: 29. 07. 2007 Příspěvky: 437 Bydliště: Praha
|
Zaslal: 19. červenec 2008, 20:12:21 Předmět: |
|
|
Vilem Otte napsal: |
#MD - Hm... ja zase muzu říct, pojďte mi všichni pomoct na mém enginu - ale když na něm dělá více lidí každý s jiným způsobem psaní, tak s organizací jsou trochu problémy (a někdy také s dokumentací výsledného kódu, ale neříkám že se to nedá ).
#Mihulik - C++ se časem moc vyhnout nedá, a já jen doporučuji se naučit, programuje se v něm dobře a přece také:
"Kolik jazyků znáš, tolikrát jsi robotem" |
No mozna se mi povedlo Mihulika zlakat Ale uvidime. V kazdem pripade si vzal k srdci tvoji poucku o robotech a bude se ucit C++ a C#, coz je urcite dobre.
Vileme, jak daleko jses s vyvojem? Ty screenshoty, co prezentujes na CH jsou nadherne. Jestli to spravne chapu, tak se zamerujes spise na grafiku, fyziku a realnej svet. Ja jsem spis opak, jde mi o herni logiku, simulaci mnoha rozmanitych objektu, oo skriptovani a treba fyziku vubec neresim a grafiku preferuju schematickou. No a protoze to programuju hezky modularne tak by to slo propojit, tedy spojit sily bychom teoreticky mohli, ale jen za predpokladu, ze to bude uzitecny - tedy musi byt predstava nejake hry, ktera by to spojeni vyuzila. _________________ - play with objects - www.krkal.org - |
|
Návrat nahoru |
|
 |
Quiark

Založen: 29. 07. 2007 Příspěvky: 816 Bydliště: Chlívek 401
|
Zaslal: 19. červenec 2008, 20:12:29 Předmět: |
|
|
[OT]Mě jen bije do očí to slovo "funkcionální". Ono to totiž znamená něco jiného, než co máš na mysli. To, co máš na mysli, se označuje slovem "procedurální".[/OT]
K tématu: Mihulik: Proč si vlastně chceš napsat vlastní engine? _________________ Mám strach |
|
Návrat nahoru |
|
 |
Augi

Založen: 28. 07. 2007 Příspěvky: 782 Bydliště: Čerčany
|
Zaslal: 19. červenec 2008, 20:34:37 Předmět: |
|
|
Quiark napsal: |
[OT]Mě jen bije do očí to slovo "funkcionální". Ono to totiž znamená něco jiného, než co máš na mysli. To, co máš na mysli, se označuje slovem "procedurální".[/OT] |
Exactly
Quiark napsal: |
K tématu: Mihulik: Proč si vlastně chceš napsat vlastní engine? |
Ať má důvod jakejkoliv, tak bych ho od toho neodrazoval. Pravděpodobně si projde několika iteracema a během toho se naučí věcí, které se z knížek naučit nelze... |
|
Návrat nahoru |
|
 |
Vilem Otte

Založen: 18. 09. 2007 Příspěvky: 462 Bydliště: Znojmo - Sedlesovice, Kravi Hora
|
Zaslal: 19. červenec 2008, 20:37:20 Předmět: |
|
|
#Quiark - funkcionální jsem to přeložil do češtiny, jsem zvyklý mluvit kompletně angl. co se programování týče ... a "procedural" jsem přeložil jako funkcionální (teda slovník mi to tak alespoň "říká").
Mihulik již psal - chce si rozšířit informace. Připadá mu to jako mnohem větší výzva než hra a chce to zkusit. (Btw. ona to mnohem větší výzva je)
#MD - Ano, zaměřuju se na grafiku, fyziku a reálnej svět. Ale prvně musím dokončit ten engine, který zrovna dělám (pak plánuju nějakej čistě ray-traced projekt ... už na to plánuju i ladící mašinu ... tedy mašiny - přece řada PC je na ladění raytraceru lepší než jedno).
Takže proti spojení sil nic nemám, ale ne zrovna teď. Možná ke konci roku (to většinou dokončuji úplně a začínám nové ). _________________ Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. |
|
Návrat nahoru |
|
 |
|