Viiveistä,
Oletetaan että minulla on tietokonepeli jonka haluan laittaa nettiin.
Ja tämä peli olisi säädetty vaikka 14 framen nopeudelle, ja pelissä on vaikka 200 imagea taikka spriteä taikka noin, ja nämä siis kaikki 14 fps.
Kysymys -
Kuinka on paree asentaa viiveet ?
1) Laitanko jokaisen framen jälkeen tarkistuksen että viivettä on vaikka säädetty 800 ms / 14 fps jokaisen framen jälkeen.
2) Laitanko jokaisen spriten taikka imagen jälkeen tämän viive tarkistuksen jotta viivettä on sekunnin osien kuluessa säädetty määrä.
Tuossa on siis peli jossa viivettä on 800ms / 1000 ms säädettynä, ja 14 frame sekuntti piirto päivitys.
---
Mietettä aiheuttaa tämä että kuumeneeko koneet enemmän jos viivet on jakautunut tasaisesti sekunttiin, vaiko jos viive on ainoastaan 14 kertaa sekunnissa.
Jos viive on jakautunut tasaisesti, niin, ehtiikö gpu jäähtyä.
Jos taas viivettä on vain 14 kertaa sekunnissa, niin, voiko olla vaaraa että gpu kuumenee liikaa.
Minulla on tässä tällä hetkellä säädetty viive tarkistus jokaisen kuvan ja spriten piirron jälkeen, mutta viive tarkistus sisältää tarkistuksen joka estää sleep(xx) käskyn toiminnan useammin kuin 1 / 20 osa sekunttia.
Eli, kuinka olisi paree säätää viiveet java peliin jossa on 200+ imagea ja 14 fps koko ruutu käytössä, minimi viiveeni on tällä hetkellä 800 ms sekunnissa ?
---
Java on kyllä niin hidas että piirtonopeutta ei tarvitse rajoittaa. Piirrät aina niin nopeasti kuin pystyt. (vaikka 600fps)
GPU tai CPU ei saisi KOSKAAN mennä rikki vaikka sitä käyttäisi miten tehokkaasti. (valitettavasti mutama tälläinen tapaus on historiassa)
Lämmöt,
Eli kumpi noista mainitsemistani tavoista olisi parempi, vaiko onko joku kolmas tapa vielä ?
gpu lämpö nousee aina käytössä, jaanko sleep viiveen tasaisesti sekunttiin vaiko pidänkö nämä frameraten mukaiset 14 viivettä ?
---
Et voi tietää, kauanko piirtäminen milläkin koneella kestää. Eli kyllä sinun pitää katsoa kelloa. Jos vain säädä jonkun kiinteän määrän viivettä niin hitaammalla koneella peli voi hidastua merkittävästi.
Hitaat koneet,
Minulla on minimi vaatimukset, ja kaikki viiveet on rakennettu minimi vaatimusten mukaisten koneitten mukaan, nopeammilla koneilla viiveitä voi sitten olla vielä enemmän, esim 950 ms / 1000 ms taikka jotain noin.
Minulla on minimi vaatimus koneelle 1.5Ghz ja NIVIDA GF5200FX, tälläisellä kokoonpanolla voi olla viivettä tuo 800 ms / 1000 ms ja 14 fps.
Hitaammilla koneilla ei voi pelejä pelata tuota 14 fps, eikä ole minun lupaa käyttää peliä, mutta silti niissäkin on minimi sleep 800 ms.
---
Haluaisin useita mielipiteitä,
Kumpaa viive käyttöä käytän pelissäni ?
1) Viive minimi 800 ms on jaettu tasaisesti sekunttiin, hieman jokaisen spriten piirron jälkeen.
2) Viive minimi 800 ms on jaettu 14 kertaa sekunnissa frameraten mukaan, kuitenkin viive on aina vähintään 800 ms vaikka framerate alhaisempi.
Kummalla tavalla gpu lämpenee vähemmän ?
Tavassa 1) ei ole koskaan pitkää piirto taikka sleep vaihetta.
Tavassa 2) on aina yksittäisiä piirto pyrähdyksiä ja sitten sleep.
---
Miksi ihmeessä haluat viivettä? Jos nyt ymmärsin, niin puhut juuri jostain sleep-komennosta etkä FPS:n rajoittamisesta. Tai miksi edes haluat lisätä sellasia aivan turhia rajoituksia, jotka estävät pelaamisen hitaammilla tietokoneilla? Entä miksi huolehdit näytönohjaimen lämpötiloista? Lautapeleissäsi ei pitäisi tapahtua mitään niin ihmeellistä, että näytönohjain kuumenisi huippuun. Tai miten saat tungettua 14 kappaletta 800 millisekunin viiveitä sekuntiin, kun sekunissa on 1000 millisekuntia?
Kun suunnitellaan tai toteutetaan projektia, ei aleta itse keksimään millä koneilla tätä voi pelata ja millä ei. Minusta tuntuu siltä, että olet päättänyt aluksi estää kaikki sellaiset pelaajat, jotka eivät käytä 6-ytimisiä prosessoreita ja tuhansien eurojen näytönohjaimia. Sitten suunnittelet pelin, joka hyvin toimisi tuhansia kertoja hitaamilla koneilla. Lopuksi ilmoitat, että olet tehnyt peliisi estoja, jotka sulkevat kaikki paitsi ns. super-tietokoneet pois. Mitä tai ketä se mahtaa hyödyttää?
Mitä jos Ohjelmointiputkassa lukisi, että sivua ei saa selata kuin Kanariansaarilta, 6-ytimisellä Intelin prosessorilla ja koneella, jossa on vihreä kotelo?
Ymmh,
Sleep viive on se joka estää tietokonetta toimimasta 100% tehoilla koko ajan.
Jokaisessa pelissä joka on kaupoissa on minimi vaatimukset, ja minun minimi vaatimukset ovat ihan asialliset, CPU 1.5Ghz ja GPU GF5200FX ja lisäksi laki vaatii että minimi vaatimukset ilmoitetaan.
Mutta, tässä viestiketjussa on aiheena se mitä sleep tapaa käyttää jotta näytönohjain kuumenee vähiten.
---
Nimimerkki kpzpt aikoo siis rangaista niitä pelaajia joiden koneen teho ei riitä täysin turhalla viiveellä.
(Mikäli oikein ymmärsin niin viive on aina vähintään 800ms/1s ja jos kone ei ehdi 200msekunnissa niin framerate tippuu. Viive pidetään aina itsepäisesti minimi 800 ms. LOL)
Aikamoinen humoristi tämä meidän kpzpt - tai siis toivotaan ainakin että tämä on huumoria.
Viive,
Haluaisin useita mielipiteitä, toivoisin aikuista mielipidettä.
Kumpaa viive käyttöä käytän pelissäni ?
1) Viive minimi 800 ms on jaettu tasaisesti sekunttiin, hieman jokaisen spriten piirron jälkeen.
2) Viive minimi 800 ms on jaettu 14 kertaa sekunnissa frameraten mukaan, kuitenkin viive on aina vähintään 800 ms vaikka framerate alhaisempi.
Kummalla tavalla gpu lämpenee vähemmän ?
Tavassa 1) ei ole koskaan pitkää piirto taikka sleep vaihetta.
Tavassa 2) on aina yksittäisiä piirto pyrähdyksiä ja sitten sleep.
---
kpzpt kirjoitti:
Haluaisin useita mielipiteitä, toivoisin aikuista mielipidettä.
Aikuinen mielipide: luovu 800 ms minimiviiveestä, siis ei minkään pituista minimiviivettä.
JaskaP kirjoitti:
Aikuinen mielipide: luovu 800 ms minimiviiveestä, siis ei minkään pituista minimiviivettä.
Aikuinen mielipide: olen harkinnut 990 ms minimiviivettä lautapeleihini, mutta, antaa nyt olla tuo 800 ms.
Ymmärräthän että gpu ja cpu lepäävät eri rytmissä, eli vaikka cpu sleep olisi 990 ms sekuntti, se ei tarkoita että gpu sleep on vastaava.
Javassa vain en voi tietää koska gpu lepää, minun täytyy luottaa että edellinen frame on piirretty ja sleep on levätty, tämä minimi 800 ms takaa minulle rauhaa, mutta, ei täyttä, nämä minimi vaatimukset täydentävät tätä turvallisuutta mitä haluan peleilleni, mutta, olen vähän ymmälläni.
En pysty auttamaan kun itsepäisesti pidät kiinni minimiviiveestäsi.
olen tullut siihen tulokseen, että kpzpt on takuuvarmasti trolli.
kpzpt kirjoitti:
Haluaisin useita mielipiteitä, toivoisin aikuista mielipidettä.
Ainoa etäisestikään järkevä tapa tehdä viive on laittaa joku järjellä perusteltavissa oleva maksimipäivitysnopeus, esim. 75 fps ja nukkua ylijäävä aika. (Tai vaikka 30 fps joka on vielä jotenkuten perusteltavissa, 14 fps nyt on täysin aivokuollut ajatus, ellei käyttäjä saa asettaa sitä itse.)
Eli jos maksimipäivitysnopeus olisi vaikka 50 fps, niin tehdään ohjelma niin, että se käyttää vähintään 20ms yhteen ruutuun. Eli jos piirtämiseen menee 17ms, niin sitten nukutaan 3ms. Jos piirtämiseen menee 25 ms (eli yli 20ms) ei nukuta ollenkaan.
Tuohon on kai monta toteutustapaa, yksi löytyy kai tuosta oppaasta:
https://www.ohjelmointiputka.net/oppaat/opas.
Mutta näytti mun silmään aika erikoiselta tehosyöpöltä. On oikeasti tärkeää ettei näytönohjaimen anneta käydä täydellä kapasiteetilla koko ajan, saati prosessorin.
Koitan päästä heittää jotain...
long aika, edellinen_aika, viive;
do {
edellinen_aika = Engine.KelloMillisekunteina;;
KäsitteleTapahtumat();
Piirra();
aika = Engine.KelloMillisekunteina;
viive = 20 - (aika - edellinen_aika);
// 1000/20 = 50, eli tämä aiheuttaisi 50 fps
if (viive>0)
sleep(viive);
while (PeliKaynnissa == TRUE);Korjasin hitusen, ja voi tuon optimoida yhdellekin muuttujalle:
long aika;
do {
aika = Engine.KelloMillisekunteina;;
KäsitteleTapahtumat();
Piirra();
aika = 20 - (Engine.KelloMillisekunteina - aika);
if (aika>0)
sleep(aika);
while (PeliKaynnissa == TRUE);Anteeksti taas kpzpt! mutta mitä hiton väliä lautapeleissä (puhutaan kuitenkin edelleen sinun lautapeli-sivustostasi? ) on viiveellä!?!?!
Siis ketään pelaajaa ei haittaa, vaikka viive olisi kolme-viisi sekuntia! Ei lautapelit mitään reaktiopelejä kuitenkaan ole!
Eli nyt se pää pois sieltä tynnyristä ja mietit vähän taas mitä olet tekemässä.
ps.
olen punppiksen kanssa täysin samaa mieltä!!
Oletko, kpzpt, koskaan miettinyt, mitä järkeä olisi valmistaa huipputehokkaita näytönohjaimia, jos ne käytössä vain kuumenisivat ja poksahtaisivat? Kyllä ne on käytettäviksi tehty, ja maailma on pullollaan raskaita 3D-pelejä, jotka ottavat irti aivan kaiken, eikä ongelmia yleensä ole.
Sen sijaan tee, kuten Grez ehdotti ja kuten matopelioppaassakin neuvotaan: valitse jokin järkevä FPS, jolla peli toimii sulavasti, ja odota jokaisen framen välissä sen verran, kuin aikaa on jäänyt yli. Jos aikaa ei jää yli, älä odota.
Toisaalta jos lautapeli ei toimi sulavasti 10 vuotta vanhalla koneella, lautapelissä on jotain vikaa. Eli aivan ensisijainen ratkaisu on toteuttaa peli järkevästi ja karsia turhat efektit. Voit myös tehdä pelin niin, että valitset saavutetun nopeuden (eli aikaylijäämän) mukaan, mitä efektejä käytetään vai piirretäänkö vain staattinen pelilauta ilman mitään animointia tai skaalausta.
User137 kirjoitti:
[C++-matopeli] näytti mun silmään aika erikoiselta tehosyöpöltä.
Pelin nukkumiskoodi on aivan pätevä vaikkakin yksinkertaisuuden vuoksi hieman suboptimaalinen (monta lyhyttä nukkumista yhden pitkän sijaan). Binaarissa ilmeisesti oli jotain hämminkiä, käänsin nyt uuden version, joka kuluttaa paljon vähemmän aikaa. Toki SDL jo itsessään takaa tietyn syöppöyden. ;)
Starcraft 2 on hyvä esimerkki pelistä joka yritti käyttää koneen tehoja liikaa. Lopputulos: käyttäjät valittaa näytönohjainten ylilämpenemisestä ja sinisistä ruuduista. (Myönnetään, omakin näyttis meni jossain Betan versiossa ylikuumaks.) Noita rajoitteita korjailtiin pitkin Beta-testiä ja kauan sen jälkeenkin. Todellisuus on että kaikki näytönohjaimet ei kestä sitä. On läppäreiden integroituja ja muita halpakortteja joissa ei oteta vastuuta täydestä toimivuudesta. Pääasia että Windows ei kaadu.
No eipä se kyllä Starcraftin vika ole, jos ylilämpenemisiä ja sinisiä näyttöjä esiintyy - ellei sitten Starcraftin mukana toimitettu näytönohjainajureita.
Tuntuisi aika absurdilta ajatukselta, että ohjelmantekijä rajoittaisi esim. GPU-kulutuksen kaikilta 50%:iin sen takia, että on muutama näytönohjainvalmistaja, jotka tekee paskaa. Toki ne voi asiakaspalvelun nimissä tehdä pätsin, joka rajoittaa nopeuksia huomatessaan koneessa olevan rikkinäisen näytönohjaimen.
Myös käyttäjä voi alikellottaa näytönohjaimensa, jos se oma näytönohjain vaikuttaa liian kuumalta tai äänekkäältä.
Jos näytönohjainta ei ole ylikellotettu ja se ylikuumenee tai toimii väärin, niin se kuuluu takuun piiriin.
Jos näyttis ja/tai prossu ei kestä vähintään 24 tuntia täydellä kuormalla pitää mennä vaatimaan rahat takas.
punppis kirjoitti:
olen tullut siihen tulokseen, että kpzpt on takuuvarmasti trolli.
Ei kai ??
Mutta oikeasti lautapelissä (shakin tapaisessa) ei pidä olla kiinteää piirtoa per sekunti. Jos esim. pelaaja miettii minuutin niin sinä aikana ei tehdä yhtään ikkunan/bufferin uudelleen piirtoa: framerate on nolla koko 60 sekunnin ajan.
Vasta kun pelaaja siirtää (eli hiiren nappi on alhaalla ja kursori liikkuu), niin sitten piirretään: framerate on hiiren positiot sekunnissa.
(Tietenkään välttämättä koko ikkunaa/bufferia ei tarvitse piirtää vain liikkeen alku ja loppu alueet.)
Nyt kpzpt haluaa piirtää vakiona 14 kertaa sekunnissa ja on huolissaan gpu+cpu:n kuumenemisesta. LOL
Javalle varmaan löytyy valmiina joku kirjasto missä nappulan siirto (=drag&drop) toimii yllä kuvatulla tavalla ettei tartte itse väsää...
JaskaP kirjoitti:
Mutta oikeasti lautapelissä (shakin tapaisessa) ei pidä olla kiinteää piirtoa per sekunti.
Voihan siinä olla turhia animaatioita (esim. animoitu tausta tai haukottelevia pelinappuloita) silloinkin, kun mitään ei varsinaisesti tapahdu. Sellainen tuntuu valitettavasti olevan nykyajan trendi.
No en mä tiedä onko se "valitettavasti". Pelit on viihdettä ja hienompi peli voi olla viihdyttävämpi. Mutta tietenkin olisi hyvä että muut asiat olisi kunnossa ennen kuin aletaan kuorruttamaan.
Metabolix kirjoitti:
Voihan siinä olla turhia animaatioita (esim. animoitu tausta tai haukottelevia pelinappuloita) silloinkin, kun mitään ei varsinaisesti tapahdu. Sellainen tuntuu valitettavasti olevan nykyajan trendi.
No okei, mutta silloinkin voisi olla niin että vasta haukottelevan nappulan animaatio käynnistäsi ikkunan uudelleen piirron.
Toki jos koko ajan liikkuu ja tapahtuu niin sitten vaikka kiinteä FPS (esim. 60 tai 30 fps) tai muuttuva FPS.
Miten muuten voi perustella tätä 14 FPS:ää? (60 ja 30 fps:lle on jonkinlaisia perusteita)
Shakissakin voi keksiä ihan hyödyllistä piirrettävää. Hiiren kohdalla olevan nappulan ja sen lailliset siirrot voi korostaa, sivustoa kun ei selvästikään ole tarkoitettu kokeneille shakinpelaajille, tai ainakin kelloa voi päivittää jos pelataan ajan kanssa.
Tuollapa muuten Javalla tehty clientti nettishakkiin:
http://www.freechess.org/Login/jin/applet.php
Ja toimii 'sattumalta' kuten selitin eli prossun käyttö nousee vain kun liikuttaa nappulaa (pyöritä nappulaa ympäriinsä muutama sekunti jotta näkyy cpu-mittarissa.)
JaskaP kirjoitti:
Miten muuten voi perustella tätä 14 FPS:ää?
kpzpt taitaa haluta, etteivät nykyaikaiset näytönohjaimet ylikuumene. :P
Muuten, kpzpt, sanoit aloitusviestissäsi "200+ imagea". Haluaisitko selventää, että mihin tarvitset yli 200 kuvaa shakkipelissä? Nappuloita on 12, kun huomioidaan molemmat värit. Pelilauta vie yhden. Minun laskujeni mukaan siinä on 13 kuvaa.
Macro kirjoitti:
kpzpt taitaa haluta, etteivät nykyaikaiset näytönohjaimet ylikuumene. :P
Yksikään nykyaikainen, ehjä ja oikein asennettu näytönohjain ei ylikuumene minkäänlaisella javaohjelmalla.
Noista kuvista, niin varjot yms efektit ehkä aiheuttaa pientä määrän kasvua. Siltikin 200 kuulostaa paljolta. Toisaalta, voisihan laudan kasata 64 osasta, yms.
Macro kirjoitti:
Haluaisitko selventää, että mihin tarvitset yli 200 kuvaa shakkipelissä?
Kyse ei varmaan ole erillisistä kuvatiedostoista vaan ruudulle piirrettävistä kuvista. Esimerkiksi nappuloita on silloin 32 ja ruutuja 64 (ellei koko lauta ole yhtenä isona kuvana, mikä ei olisi kovin kätevää).
Grez kirjoitti:
No en mä tiedä onko se [animointi ym.] "valitettavasti".
Ei ehkä itsessään, mutta se on ainakin valitettavaa, jos yksinkertainen shakki väännetään tuollaisilla niin solmuun, että pelaamiseen tarvitaan upouusi näytönohjain. Vähintäänkin pitäisi olla nappi, josta turhat kilkkeet saa pois päältä.
14 fps,
Minulla on tuo 'ilmojein_pilotit_1917' lautapeli säädettynä 14 fps, shakki taasen on tällä hetkellä muhkeat 6 fps kun animaatiota on ruudulla ja kun animaatiota ei ole ruudulla on shakki 1 fps, tämä 1 fps koska jos liikuttaa selainta voi java applet ikkuna tyhjentyä, ajattelin korjata tuon kenties jotenkin 0.333 fps taikka 0.2 fps arvoilla sitten myöhemmin, mutta, peli kirjastoni ei juuri nyt osaa käsitellä fps arvoissa kuin kokonaislukuja.
Ajattelin tuon 14 fps taikka enintään 16 fps jättää noihin minun arcade lautapeleihini, kuten tuo 'ip1917' ja 'luolaston lentelijät', taasen nämä peruslautapelit saavat olla alhaisella fps arvolla, mahdollisesti poistan pinta tyylin piirtämisen niistä ja käytän dirty rectangleja.
Mutta tämän keskustelun aiheena oli -
Kumpaa viive käyttöä käytän pelissäni ?
1) Viive minimi 800 ms on jaettu tasaisesti sekunttiin, hieman jokaisen spriten piirron jälkeen.
2) Viive minimi 800 ms on jaettu 14 kertaa sekunnissa frameraten mukaan, kuitenkin viive on aina vähintään 800 ms vaikka framerate alhaisempi.
Kummalla tavalla gpu lämpenee vähemmän ?
Tavassa 1) ei ole koskaan pitkää piirto taikka sleep vaihetta.
Tavassa 2) on aina yksittäisiä piirto pyrähdyksiä ja sitten yksittäinen sleep, tällä tavalla molemmat sekä piirto että sleep vaihe on hieman pidempänä.
mietin kovasti että kumpi olisi parempi ratkaisuista, saman verran piirretään molemmissa, ja eri tietokoneet ovat taas erillaisia, kuten eri käyttöjärjestelmien opengl ja d3d ajuritkin, tai jotain noin.
---
Lisäys.
'Ilmojein_pilotit_1917' pelissä on noin 200+ imagea ja 14 fps, ja se on jo aika paljon webbi pelissä, 80% imageista on kuitenkin jotain 16x16 pixeliä.
Shakissa on tällä hetkellä 32 nappia ja 32 varjoa ja 1 lauta, marsalkkashakissa neljä ylimääräistä nappia varjoineen.
Osaat aina kysyä aiheesta kun aiheesta täysin epäoleellisia kysymyksiä.
Kuten monet ovat jo sanoneet joku FPS on täysin irrelevanttia jossain java web appletissa.
Sen sijaan että takerrut näihin epäoleellisiin asioihin, voisit vaikka aluksi oikeasti opetella ohjelmoimaan.
Sitten kun se on hallussa näkisit itsekkin miksi mm. tämä FPS on tässä epäoleellista.
Mutta kun kuitenkin jatkat ohjeista huolimatta kivikkoista tietäsi, ole hyvä vaan, on kyllä päivän piristävää aina.
Kun näköjään väännät väkisin noin tyhmästä kysymyksestä, vastataan nyt siihenkin.
Jos pidät taukoa jokaisen spriten jälkeen, CPU luultavasti kuumenee enemmän, koska sleep-funktion kutsuminenkin vie aikaa ja käyttöjärjestelmä joutuu jatkuvasti hyppimään ohjelmasta toiseen. Lisäksi useimmissa käyttöjärjestelmissä kellon tarkkuus on 1 tai 10 millisekuntia, jolloin 200 sleep-kutsusta tulee aina vähintään 200 millisekuntia, jolloin FPS on aina alle 5.
Myös GPU:n kannalta luultavasti olisi parempi nukkua kerralla pidempään, mutta kun piirtoa kuitenkin tapahtuu monta kertaa sekunnissa, asialla tuskin on mitään havaittavaa vaikutusta. Jos koneella pyörii samalla muita GPU:ta käyttäviä asioita (kuten Windowsin Aero-työpöytä), kannattaa piirtää mahdollisimman paljon kerralla, koska myös piirtokontekstin vaihtaminen kuluttaa ylimääräistä tehoa.
sleep,
Metabolix ensin puhuu tyhmästä kysymyksestä, näin hän alentaa minun aihettani, vaikka aiheeni onkin ihan asiallinen, ja olen sen kattavammin käynyt lävitse mitä hän vastauksessaansa itse ymmärtää.
Esim mitä tuohon 200 sleep kutsuun, niin minulla on tällä hetkellä jokaisen kuvan jälkeen sleep kutsu tämä on 14 * 200 sekunnissa, tämä tuo turvan hitaisiin koneisiin jotka eivät nuku tuota 14 kertaa sekunnissa koska framerate on vaikka alle 3 fps.
Tuo sleep kutsu on rajattu juuri nyt 1/20 kertaan sekunnissa, vaikka sitä kutsutaankin joka kuvan jälkeen, mahdollisesti muutan sen 1/30 kertaan sekuntti, taikka kenties sitten vain jätän se 1/14 kertaan sekuntti.
Myöskin mittaan sen ajan mitä sleep sitten kestääkään, niin, nanotimerilla, jotta seuraavat sleepit ovat sitten edellistä tarkentavia.
Myöskin minulla on tämä java sleep daemon päällä joka takaa sen että myös win koneissa on sleep tarkkuus 1 ms.
Kiitos kuitenkin kun jotkut vastasi siihen mitä kysyinkään, minä tein taas sen virheen että unohdin lisätä että vaikka kysymys on tärkeä niin se on osittain hieman kujeileva, koska molemmilla sleep tavoilla on saman verran sleeppiä ja saman verran ohjelmaa suorituksessa, ajattelin vain käynnistää yhden keskustelun, ei ollut mistään suuri suuntaisesta foorumin ykkös keskustelusta kyse.
---
kpzpt kirjoitti:
Metabolix ensin puhuu tyhmästä kysymyksestä, näin hän alentaa minun aihettani, vaikka aiheeni onkin ihan asiallinen, ja olen sen kattavammin käynyt lävitse mitä hän vastauksessaansa itse ymmärtää.
Olen itse huomannut, että yleisesti ottaen Metabolixin kommentteja ei pidä mennä aliarvioimaan, ne saattavat olla hieman kärkkäitä, mutta siitä huolimatta ne osuvat mitä todennäköisemmin aina oikein. Voisit kenties joskus kuunnella, mitä sinulle yritetään sanoa, niin ehkä asiat alkaisivat mennä oikeaan suuntaan. Voisit myös esittää nuo kysymyksesi sellaisessa sanamuodossa, ettei tarvitse alkaa leikkimään mitään FBI-agenttia, että tekstistä saa tolkkua...
kpzpt kirjoitti:
olen sen kattavammin käynyt lävitse mitä hän vastauksessaansa itse ymmärtää
Jos olet käynyt sen kattavammin lävitse, miksi olet täällä kyselemässä?
kpzpt kirjoitti:
molemmilla sleep tavoilla on saman verran sleeppiä ja saman verran ohjelmaa suorituksessa
Juuri tässä on se kohta, jossa sinun ajatuksesi menee pieleen. Nukuttavan ajan laskeminen vie aikaa. Sleep-funktion kutsuminen vie aikaa. Asian käsittely käyttöjärjestelmän puolella vie aikaa. Prosessin vaihtaminen käyttöjärjestelmässä vie aikaa. Siksi useampi sleep aiheuttaa enemmän laskentaa.
Esimerkiksi minun koneellani 14 * 200 = 2800 yhden nanosekunnin nukkumista (Thread.sleep(0,1)) kestävät ilman muuta kuormaa 3,1 sekuntia ja kuluttavat 0,1 sekuntia prosessoriaikaa. Jos laitan taustalle kunnolla muuta kuormaa, saan yhteensä aikaa kulumaan 30 sekuntia ja prosessoriaikaa 0,3 sekuntia. (Vähensin jo luvuista ajan, joka ohjelmalla kuluu kutsulla Thread.sleep(0).) Toisin sanoen melkoinen osa kaikesta prosessoritehosta menee pelkkään nukkumiseen, ja lisäksi nukuttu aika on paljon toivottua pidempi – kuorman kanssa todella paljon.
kpzpt kirjoitti:
Myöskin mittaan – – nanotimerilla, jotta seuraavat sleepit ovat sitten edellistä tarkentavia. – – sleep tarkkuus 1 ms.
Mitä hyötyä on mitata nanotimerilla, jos se tarkkuus on kuitenkin vain millisekunteja? Esimerkiksi tuossa edellisessä testissäni nukkumisajan vaihtaminen nanosekunnista millisekunniksi ei muuta lopputulosta, eli selvästikin nanosekunti pyöristyi ylöspäin suunnilleen millisekuntiin.
kpzpt kirjoitti:
1/20 kertaan sekunnissa
Paljonko on 1/20 kertaa sekunnissa? Kerran 20 sekunnissa?
Nanosekuntti,
- Java Sleep () käsky vaatii hieman enemmän säätelyä mitä nyt on kirjoitettuna, ensinnäki Thread.sleep(0,1) ei ole mahdollinen koska pienin aika jonka sleep nukkuu on 1 ms eli Thread.sleep(1,0).
- Järki siihen minkä takia käyttää nanotimeria vaikka se ei mittaa kuin ms tarkkuudella, on se että millisekuntti timer mikä javassa on ei mittaa kuin 15 ms tarkkuudella arvioisin.
- Minulla on tietenkin myös jo valmiiksi ajateltu nuo mitä pidit ongelmana.
- Esim, jos minulla on 200 * 14 sleep käskyä sekunnissa, niin, minä tietenkin ennen jokaista sleeppiä tarkistan nanotimerilla onko sleeppiin edes tarvetta, koska minun omassa tietokoneessani 200 imagea kestää kait jotain 10-30 ms piirtää, eli siinä ei olisi läheskään 200 kappaletta sleep 1 ms taukoja, nanotimeri tarkistaa ja säätää kuinka useia näitä sleeppejä tarvitsee.
Myöskin vaikka kysyinkin tasapuolisena tämän viestiketjun ekan kysymyksen koskien tätä sleep käyttötapaa, niin tämä että sleeppiä pitää useammin kuin frameraten mukaan, on enin osin suunnattu hitaisiin koneisiin joissa on vaikkapa testatessa vain 3 fps vauhti, eli siinä olisi sitten 3 kappaletta 800ms / 3 taukoa, kun taas laitan sleepin joka kuvan jälkeen ja minimi 20 kertaa sekunnissa on taukoja myös 3 fps koneessa tuo 20 kappaletta, vaikka siinäkin yhteenlaskettu taukoilu on vain 800 ms.
Olen taas kerran pahoillani suomenkieleni takia, sitä taas kehuttiin tuossa äsken.
Mutta, sleep käskyä ja sleeppiä voi pitää niin monella tapaa ohjelmassa että tämä keskustelu varmaankin ohjautuu taas moneen eri kinastelevaan suuntaan.
Minun täytyy ottaa huomioon että kaikilla koneilla olisi sama minimi sleep jotta en joudu tilanteeseen jossa joudun jollekulle selittämään miksi hänen tietokoneensa sleep oli niin alhainen.
---
kpzpt kirjoitti:
ensinnäki Thread.sleep(0,1) ei ole mahdollinen koska pienin aika jonka sleep nukkuu on 1 ms eli Thread.sleep(1,0).
Olet väärässä, lue Javan dokumentaatiota.
kpzpt kirjoitti:
Esim, jos minulla on 200 * 14 sleep käskyä sekunnissa, niin, minä tietenkin ennen jokaista sleeppiä tarkistan nanotimerilla onko sleeppiin edes tarvetta
Tarkoitatko nyt tosissasi, että mitä enemmän aikaa on kulunut, sitä enemmän nukutaan? Tässä keskustelussa on jo toistakymmentä viestiä, joissa selitetään, miksi niin ei pidä tehdä.
kpzpt kirjoitti:
Minun täytyy ottaa huomioon että kaikilla koneilla olisi sama minimi sleep jotta en joudu tilanteeseen jossa joudun jollekulle selittämään miksi hänen tietokoneensa sleep oli niin alhainen.
Jos maailmasta löytyy edes yksi henkilö, jota oikeasti kiinnostaa, miksi hänen tietokoneensa sleep oli niin alhainen, löytyy varmaan miljoonia, joita kiinnostaa, miksi heidän koneidensa sleep on niin korkea.
Mutta omapa on pelisi, omat virheesi, oma huolesi, kun ei väki halua pelata.
Thread.sleep(),
Tuo Java documentaatio ei ole oikeassa, timereitten kohdalla, se kertoo mitenkä javan olisi tarkoitus toimia, mutta se ei kerro mitenkä java toimii.
Pienin aika minkä java sleeppaa on 1ms eli Thread.sleep(1) taikka Thread.sleep(1,0), tällöinkin on eri käyttöjärjestelmissä huimia eroja, eteenkin windows koneet ovat epätarkkoja, niihin pitää asentaa yksi documentoimaton sleep daemon, jotta ne kykenevät 1 ms tarkkuuteen, muuten ovat noin 15 ms tarkkuudella, linux taas on oletukseltaansa 1ms tarkkuudella, javassa ei ole alle 1ms sleeppiä vaikka dokumentaatio niin väittääkin.
---
Myöskin loppu osa viestistäsi metabolix on hieman epäkelpoa, mutta, johtuu varmaan nuoruutesi uhmasta.
---
kpzpt kirjoitti:
Tuo Java documentaatio ei ole oikeassa, timereitten kohdalla, se kertoo mitenkä javan olisi tarkoitus toimia, mutta se ei kerro mitenkä java toimii.
Jaa, no minkäs exceptionin sitten sait, kun kerran sleep(0,1) ei ollut mahdollinen? Metabolix jo viestissään 23:34:34 kertoi tuon, että käytännössä sleepissä kestää pidempään kuin mitä on käsketty nukkua. Kannattaisiko lukea mihin vastaa, ennen kuin vastaa?
kpzpt kirjoitti:
Thread.sleep(),
Tuo Java documentaatio ei ole oikeassa, timereitten kohdalla, se kertoo mitenkä javan olisi tarkoitus toimia, mutta se ei kerro mitenkä java toimii.
Pienin aika minkä java sleeppaa on 1ms eli Thread.sleep(1) taikka Thread.sleep(1,0), tällöinkin on eri käyttöjärjestelmissä huimia eroja, eteenkin windows koneet ovat epätarkkoja, niihin pitää asentaa yksi documentoimaton sleep daemon, jotta ne kykenevät 1 ms tarkkuuteen, muuten ovat noin 15 ms tarkkuudella, linux taas on oletukseltaansa 1ms tarkkuudella, javassa ei ole alle 1ms sleeppiä vaikka dokumentaatio niin väittääkin.
---
Myöskin loppu osa viestistäsi metabolix on hieman epäkelpoa, mutta, johtuu varmaan nuoruutesi uhmasta.
---
:D
Vielä tähän asti olen pitänyt sinua umpiluupäisenä idioottina.
Mutta jos nyt alat jo väittämään että Java omat dokumentaatiot on väärin ja sinä olet oikeassa.
Sen jälkeen ei voi muuta todeta että hyvää isän päivää ja onnea valitsemallasi tiellä.
ps. me ammattilaiset käytämme noita samaisia ohjeita jotta saamme tehtyä toimivia ohjelmistoja.
_Pete_ kirjoitti:
ps. me ammattilaiset käytämme noita samaisia ohjeita jotta saamme tehtyä toimivia ohjelmistoja.
Niin ja se vielä unohtu:
käyttämällä noita ohjeita ollaan saatu toimivia systeemejä.
ps. en ole töissä tiedolla ja tekemässä VR
Kyllähän dokuissakin sanotaan, että lopullinen tulos riippuu järjestelmästä. Kyseinen tarkennus löytyy ainakin kutosversiosta alkaen, 1.5.0:sta puuttui. Onkohan sitten virhe olettaa, että ohjelmoijalta löytyisi edes perusymmärrys ohjelmointikielen toiminnasta ja järjestelmän rajoitteista? Järkikin sanoo, että pienillä arvoilla virheiden täytyy olla suuria.
kpzpt kirjoitti:
Minulla on tuo 'ilmojein_pilotit_1917' lautapeli säädettynä 14 fps, shakki taasen on tällä hetkellä muhkeat 6 fps kun animaatiota on ruudulla ja kun animaatiota ei ole ruudulla on shakki 1 fps, tämä 1 fps koska jos liikuttaa selainta voi java applet ikkuna tyhjentyä,
Jaaha, sulla on siis homma sittenkin oikeansuuntainen.
Mutta kyllä appletin uudelleen piirron pitäisi tapahtua automaattisesti GUI'n toimesta eli tarkistapa koodisi, niin saat sen 0 FPS, kun mitään animaatiota yms. ei ole.
kpzpt kirjoitti:
Ajattelin tuon 14 fps taikka enintään 16 fps jättää noihin minun arcade lautapeleihini, kuten tuo 'ip1917' ja 'luolaston lentelijät', taasen nämä peruslautapelit saavat olla alhaisella fps arvolla, mahdollisesti poistan pinta tyylin piirtämisen niistä ja käytän dirty rectangleja.
'ilmojein_pilotit_1917' ja 'luolaston lentelijät' ohjelmia ei voi mitenkään sanoa lautapeleiksi eikä edes arcade lautapeleiksi. Lienevät lähinnä toiminta- tai ammuskelupelejä.
Tässäkin viestiketjussa olisi ollut paljon vähemmän sekoilua jos olisit heti kertonut että kyse on reaaliaikaisista (toiminta)peleistä eikä vuoropohjaisista lautapeleistä.
Jessus sentään...
GUI,
Voitko selittää tuota GUI'n toimesta hieman, oman java tuntemukseni mukaan, applet ikkuna voi jäädä tyhjäksi ellei sitä piirrä säännöllisesti, tämä käy kun ikkunaa liikuttaa pois 'ruudulta' ja takaisin, taikka 'tärisyttää' hieman, lie eri käyttöjärjestelmissä ja selaimissa eri tavalla.
'Ilmojein pilotit 1917' on lautapeli, kuten tulee olemaan myös 'luolaston lentelijät', lautapeli mullistus on jo alkanut maailmalla, on kaikenlaista pintaa ja vempainta, joilla tulevaisuuden lautapelit pelataan pahvin sijaan, tämä on vihreämpi suunta mikä lautapeleissä on tulossa, pahvi ja paperi ollaan osittain korvaamassa tietokone tasoilla ja varmaan uskoisin että myös piirtoheittimillä ja kaikella muullakin vastaavilla.
Lautapelien ei tarvitse olla vuoropohjaisia, minun pelini tulevat olemaan reali ajan live pelejä sekä vuoropohjaisia ja jne mitä kaikkea sitten keksinkään.
Minulla on tarkoitus valmistaa vain lautapelejä, koen että nautin tästä ideasta eniten.
kpzpt kirjoitti:
Voitko selittää tuota GUI'n toimesta hieman, oman java tuntemukseni mukaan, applet ikkuna voi jäädä tyhjäksi ellei sitä piirrä säännöllisesti
Millaisessa ynmpäristössä tällainen on käynyt? Itselleni ei vielä tullut moista vastaan kertaakaan. Kuitenkin pelaaminen on todella tuskallista, johtuen luultavasti alhaisesta ruudunpäivityksestä. Voisit vaikka palkita nopeammat koneet paremmalla FPS:ä, tai edes laittaa mahdollisuuden asetuksiin.
Tällä hetkellä pelaaminen ei ole miellyttävä kokemus sivuillasi. Esimerkiksi aapelissa / vastaavissa palveluissa on enemmän laskentaa vaativia sovelluksia nopeammalla ruudunpäivityksellä, eikä mitään ongelmia ole ollut.
no, luolastolentelyt ja vastaavat eivät ole yksinkertaisesti lautapelejä. Aika yhtä lähellä lautapeliä kuin vaikka Doom.
kpzpt kirjoitti:
Voitko selittää tuota GUI'n toimesta hieman, oman java tuntemukseni mukaan, applet ikkuna voi jäädä tyhjäksi ellei sitä piirrä säännöllisesti
Niin se pitäisi toimia ellei käyttämäsi Opengl-kirjasto ole aivan aivokuollut. Ehkä joku paremmin Javaa+Opengl'ää tunteva osaa neuvoa mikä kohta koodista puuttuu tai on väärin tehty.
kpzpt kirjoitti:
'Ilmojein pilotit 1917' on lautapeli, kuten tulee olemaan myös 'luolaston lentelijät', lautapeli mullistus on jo alkanut maailmalla
Vakiintunut käsitys termistä lautapeli ei vastaa sinun käsitystäsi. Lue vaikka: http://fi.wikipedia.org/wiki/Videopelilajityypit
Voit tietysti käydä muokkaamassa Wikipedian törkeästi 'väärää' artikkelia 'mullistusta' vastaavaksi. Odotamme malttamattomina kuin innostunut mulli.
GUI ja lautapeli,
Tuo että appletti säilyttää sisällyksensä on varmaankin totta kun käyttää komponentteja kuten JLabel jossa sitten on kuva sisällä, mutta, minulla on vain Bufferedimageja käytössä bufferstrategy(2):ssa, jotenka kun liikutan selainta ruudun ulkopuolelle ja takaisin taikka kun selain tärähtää, niin, tällöin appletin pinta ei enää ole kuvan kanssa, vaan pyyhkiytynä mustaksi RGB(0,0,0) väriksi, kokeile omalla javalla laittaa appletti jossa on kuva jota ei päivitetä ja siirrä siintä sitten selain ikkunaa ruudun ulkopuolelle ja takaisin, tällöin kuva on poissa, taikka jos hiirirulla skrollaat ruutua jossa appletti on, minulla ei ole viallisia osia koodissani, en ihan vielä ole julkaisu koodia kirjoittanut, mutta, koodini on ehjää ja surface eli pinta eli applet-canvas-bufferstrategy(2) tyylillä katseltuna oikein kirjattuna.
Myöskin jos kirjaimellisesti laitan pelini laudan päälle ruudulla, niin, pelini ne ovat tällöin lautapelejä, vaikka sitten laudan päällä olisikin animaatiota ja kaikenlaista toimintaa, mitä ei perinteisissä lautapeleissä olekkaan.
Tietokone peli tyylejä tulee lisää vielä tänäkin päivänä, kenties minä sitten olen mukana aloittamassa ainakin täällä suomessa uutta genreä, videolautapelit, hieman tuollainen idea minulla tässä on, eli perinteisenkin tyylin pelejä laudan päälle asettuneena.
---
kpzpt kirjoitti:
Myöskin jos kirjaimellisesti laitan pelini laudan päälle ruudulla, niin, pelini ne ovat tällöin lautapelejä, vaikka sitten laudan päällä olisikin animaatiota ja kaikenlaista toimintaa, mitä ei perinteisissä lautapeleissä olekkaan.
Tuleeko hampurilaisesta pizza jos kirjaimellisesti laitan sen pizzalautaselle?
Teen tällä hetkellä tietokoneversiota eräästä lautapelistä, niin että kaikki oleellinen pelimekaniikka säilyy ennallaan, mutta tietokone hoitaa sääntötarkistukset ja piirtää hienot 3D-grafiikat. Se on lautapeli, koska sen voi yhtä hyvin toteuttaa fyysisellä pelilaudalla kuten esikuvansakin. Se ei ole lautapeli jos koodaan 2D-ammuskelupelin jossa taustalla näkyy pelilauta.
Toki luolalentelykin voi olla lautapeli, jos sen pelilogiikka on lautapelaamiseen mukautettu. Tietokoneistetussa "lautapelissä" voi toki olla animaatioita, mutta jotta sitä voi kutsua lautapeliksi, niin peliä pitäisi voida pelata samoilla säännöillä ja pelimekaniikalla pelilaudallakin.
Heh,
En tiedä tuleeko hampurilaisesta pizza, mutta pelistä tulee lautapeli kun pelin laittaa laudalle.
2D-ammuskelupeli on tietenkin jo hieman monimutkaisempaa käsittää lautapeliksi, mutta demokratian koko idea on laittaa tälläisiä ideoita ihmisten käyttöön.
---
Wikipedia kirjoitti:
A board game is a game in which counters or pieces are placed, removed, or moved on a premarked surface or "board" according to a set of rules.
Lautapeliin liittyy oleellisesti se että on säännöt, joiden mukaan liikutellaan pelimerkkejä ennaltamäärättyihin kohtiin. Lautapelit eivät myöskään koskaan ole reaaliaikaisia siinä mielessä että mitään ei tapahdu jos kukaan ei juuri suorita siirtoa.
Tällä logiikalla toikin on varmaan lautapeli: http://home.nyan.fi/~blaze/wanko-lautapeli.jpeg
Hmmh,
Tuo boardgame määritelmä voi olla hyvinkin viime vuosisadan ekalta puoliskolta.
Nykyään on tietokoneet ja lautapelitkin tulevat tietokoneisiin, uskoisin että tulevat usean genren voimin, yksi lautapeli genre on sellainen joka pyrkii olemaan mahdollisimman identtinen mahdollisen esikuvan taikka perinteisen lautapelin kanssa, ja toinen lautapeli genre mikä on tulossa on sellainen jossa on sitten kaikenlaista koriste grafiikkaa ja hienostelua mukana.
---
kpzpt kirjoitti:
Nykyään on tietokoneet ja lautapelitkin tulevat tietokoneisiin, uskoisin että tulevat usean genren voimin, yksi lautapeli genre on sellainen joka pyrkii olemaan mahdollisimman identtinen mahdollisen esikuvan taikka perinteisen lautapelin kanssa, ja toinen lautapeli genre mikä on tulossa on sellainen jossa on sitten kaikenlaista koriste grafiikkaa ja hienostelua mukana.
Grafiikat ovat täysin irrelevantti asia sen suhteen onko tietokonepeli määriteltävissä lautapeliksi. Pelimekaniikka on oleellinen asia. Jos heitetään romukoppaan kaikki vanhat määritelmät niin yhtä hyvin voit kutsua pelejäsi vaikka korttipeleiksi ja päättää että olet juuri määritellyt korttipelit uusiksi. On eri asia onko kukaan kanssasi samaa mieltä - kuten tässä tapauksessa.
Lautapeli on minun mielestäni sellainen peli jota pelataan ilman tietokonetta pelilaudalla. Tietokoneella ja sen lautapelisovelluksilla vain simuloidaan tunnetta joka tulee lautapelin pelaamisesta ystävien kanssa, se on sosiaalinen tapahtuma. Onhan noita ollut elektronisiakin lautapelejä jo kauan, mutta pohjaidea on kuitenkin se että kaksi tai useampi henkilö pelaavat peliä saman pelipöydän äärellä vuoropohjaisesti.
kpzpt kirjoitti:
demokratian koko idea on laittaa tälläisiä ideoita ihmisten käyttöön.
Demokratian idea on kylläkin se, että päätetään yhteisesti yhteisistä asioista - ei mikään (omituisten) ideoiden tarjoaminen ihmisten käyttöön.
groovyb kirjoitti:
Lautapeli on minun mielestäni sellainen peli jota pelataan ilman tietokonetta pelilaudalla. Tietokoneella ja sen lautapelisovelluksilla vain simuloidaan tunnetta joka tulee lautapelin pelaamisesta ystävien kanssa
Mielestäni tämä ei ole lautapelimääritelmän kannalta olennaista. Minusta olisi ihan mahdollista tehdä yhdenkin pelattava lautapeli. Ja tietokonetoteutuksissa toki voidaan pelata tietokonetta vastaan.
Grez kirjoitti:
Minusta olisi ihan mahdollista tehdä yhdenkin pelattava lautapeli.
Onhan noita olemassakin reippaasti. Esimerkiksi: http://en.wikipedia.org/wiki/Peg_solitaire
Lautapelin kannalta olennaista on, että on jonkinlainen pelialusta (lauta) millä pelataan ja nappuloita joilla pelataan ennalta määrättyjen sääntöjen mukaan.
kpzpt kirjoitti:
pelistä tulee lautapeli kun pelin laittaa laudalle.
Onko CaveFlyer siis laitettu laudalle, kun se kerta on mielestäsi lautapeli? Se olisikin mielenkiintoinen nähdä.
Eihän nyt caveflyer sinänsä olisi vaikea toteuttaa lautapelinä. Tehtäisiin vaikka kuusikulmioista ruudukko jossa olisi luola (seinät ja lentelyalue). Letämisen voisi tehdä vaikka niin että ennen nopan heittoa pitäisi valita suunta mihin mennään ja sitten heitettäisiin kahta noppaa. Toinen noppa määräisi paljonko kuljetaan valittuun suuntaan ja toinen noppa kertoisi "painovoiman" eli paljonko alusta liikutettaisiin alaspäin, ja seiniin ei saisi osua. Sitten lentelyalueella voisi olla erivärisiä alueita, esim. tykkien vaikutusalue, jolloin taas heitettäisiin noppaa että tuliko osuma vai ei.
En tiedä saisiko säännöistä tehtyä sellaisia, että ketään kiinnostaisi pelata, mutta periaatteessa olisi mahdollista.
Grez kirjoitti:
Eihän nyt caveflyer sinänsä olisi vaikea toteuttaa lautapelinä.
En tiedä saisiko säännöistä tehtyä sellaisia, että ketään kiinnostaisi pelata, mutta periaatteessa olisi mahdollista.
Toki, mutta ei se siitä mielestäni tee silti lautapeliä. Ongelma siinä on se että kyseessä olisi kaksi eri peliä. Lautapeliversio olisi vain tietokoneversiota esikuvanaan käyttämä kyhäelmä täysin erilaisilla säännöillä. Mieleen tulee vanhat lisenssipelit, missä peliyhtiö on ostanut elokuvayhtiöltä lisenssin tehdä elokuvaan pohjautuva peli. Pelin nimi ja kansikuva otetaan elokuvasta, mutta muuten näillä kahdella ei olekaan keskenään mitään tekemistä.
Lähemmäksi samoja sääntöjä voisi päästä jollain "ohjaa pallo labyrintistä" tyylisellä ratkaisulla, missä toinen pelaaja saisi heitellä kentälle "ohjuksia" pallon ollessa tietyllä alueella. Mutta ei sitäkään saa niin lähelle alkuperäistä, että voisi puhua samasta pelistä. Sen takia olisikin mielenkiintoista tietää miten kpzpt siirtää luolalentelynsä laudalle.
Jos pystyt toteuttamaan tietokone-lautapelin oikeaksi pahvi-lautapeliksi, ja pelata sitä kavereides kanssa niin silloin pysytään vielä määritelmässä. Luolalentely ei millään ajatuksen tasolla käänny lautapeliksi.
Otetaan nyt vaikka Afrikan tähti. Joka pelaaja ottaa nappulastaan kiinni ja alkaa yhtäaikaa kuljettamaan sitä maaliin päin. Eli ei aleta tekemään mitään moderneja lautapelin määritelmiä, ei ole mitään logiikkaa.
Jep, itsekin määrittelen "lautapeleiksi" vain ne kaikki pelit, jotka voidaan siirtää ihan oikeiksi peleiksi. Laskisin lisäksi osan "korttipeleistä" (en tarkoita perinteisistä pelikorteista koostuvia pelejä) lautapeleiksi, mutta en kyllä mitään "reaaliaikaisia" luolalentelyitä.
Aihe on jo aika vanha, joten et voi enää vastata siihen.
