[DHTML] Project "Snowstorm"

[Clay]

Het hoeft ook niet over 3 weken af oid het zal best ff duren. Kleine update van mijn kant dan:

• Beehive2 (als't zo gaat heten) is eigenlijk zga af. Ik ben nu met js+XML aan spelen, en dat is in IE en MOZ betrekkelijk makkelijk, dus dat wordt misschien een standaard feature.
• Ben bezig met mijn js-OO tuto Is voor snowstorm misschien ook handig aangezien dit wel behoorlijk OO wordt.

[Woudloper]

OK Clay... Ziet er goed uit...

Tutor hoeft niet mega uitgebreid al zeg ik hetzelf. Gewoon dat we even weten wat de opties zijn en ja je weet het drm wil graag een object model

[drm]

Woudloper:
drm wil graag een object model

wmb is dit nog steeds een brainstorm, hoor. Ik hoop over een week of anderhalf die site ff een zwengel gegeven te hebben, dat we daar de belangrijkste dingen kunnen verzamelen, etc.

[maartenvdv737]

Ik weet niet of het al voorbij is gekomen, maar voor het berekenen van de kortste route kan je zoals iemand al zei A* gebruiken, maar is je map erg groot en zijn er veel mogelijke routes, dan moet je toch overwegen om SMA* of IDA* te gebruiken.

SMA* is een algoritme dat al het vrije geheugen gebruikt om vorige knopen in een zoekboom bij te houden. Is de ruimte vol, dan gooit hij de oudste weg.

IDA* is ook een variant van A*, maar deze stelt een limiet aan je kostenfunctie f(n), waarbij f(n)=g(n)+h(n). Als er geen route is gevonden, dan wordt de limiet van f(n) opgehoogd. Je doet een beetje dubbel werk, maar je hebt veel minder geheugen nodig!
g(n) is de kosten om een knoop uit te klappen.
h(n) is de heuristische functie die bepaalt of een knoop misschien dichter bij je doel komt dan andere knopen.

Succes ermee!

[LuCarD]

Op vrijdag 28 juni 2002 17:18 schreef maartenvdv het volgende:
Ik weet niet of het al voorbij is gekomen, maar voor het berekenen van de kortste route kan je zoals iemand al zei A* gebruiken, maar is je map erg groot en zijn er veel mogelijke routes, dan moet je toch overwegen om SMA* of IDA* te gebruiken.

SMA* is een algoritme dat al het vrije geheugen gebruikt om vorige knopen in een zoekboom bij te houden. Is de ruimte vol, dan gooit hij de oudste weg.

IDA* is ook een variant van A*, maar deze stelt een limiet aan je kostenfunctie f(n), waarbij f(n)=g(n)+h(n). Als er geen route is gevonden, dan wordt de limiet van f(n) opgehoogd. Je doet een beetje dubbel werk, maar je hebt veel minder geheugen nodig!
g(n) is de kosten om een knoop uit te klappen.
h(n) is de heuristische functie die bepaalt of een knoop misschien dichter bij je doel komt dan andere knopen.

Succes ermee!

Het zal wel aan mij liggen, maar ik snap dit nu al niet meer...
Wat is A*? SMA*? of IDA*? Zijn dat bepaalde algorimtes? Zijn die misschien ergens beschreven??

Ik zal met veel plezier over jullie schouder meekijken hoe het project zal verder lopen....

* LuCarD houdt van GOOGLE...
http://www.eecs.umich.edu/~chbrooks/pages/rn/chapter4.html

[drm]

maartenvdv:
[A* vs. SMA* en IDA*]

thnx Dat wordt op den duur uitzoeken welke het beste is, denk ik.

_edit:

LuCarD
Het zal wel aan mij liggen, maar ik snap dit nu al niet meer...

Lees even het hele topic door. oh,when? heeft er al wat over gepost. Dit zijn pathfinding algoritmes (hoe kom ik het snelst van A naar B, terwijl er obstakels in voorkomen)

[daaf258]

*schop*

[off-topic mode]

Adun Toridas DRM
misschien ook iets voor in het spel ?
For Aiur
En taro Adun
Hefnarkentix

[/off topic mode]

[melp]daaf(258)

[drm]

<sub>woei, de eerste keer dat ik daaf zie posten

[off-topic mode]</sub>

daaf258:
Adun Toridas DRM drm^{* drm}
misschien ook iets voor in het spel ?
For Aiur
En taro Adun
Hefnarkentix

^{* drm} In het kader van Front spel nicknames goed
^{[/off topic mode]}

Nog in voor graphics, daaf? Krijg je ook een credit

[Juup]

Over de {} conventies, als je een "Javascript Beautifier" hebt die configureerdbaar is, dan is er geen probleem.

Op http://www.rbqline.nl/sc/game.html staat er een die ook javascript aan schijnt te kunnen. Ik weet niet hoe configureerbaar die is. Eigenlijk zou de hele wereld natuurlijk deze conventie aan moeten houden :

code:

function MyFunction()
{
  //comment
  int myFirstInt = 0;
}

[drm]

Jaaap:
Op http://www.rbqline.nl/sc/game.html staat er een die ook javascript aan schijnt te kunnen.

verkeerde linkje

[Juup]

Op maandag 01 juli 2002 13:15 schreef drm het volgende:
verkeerde linkje

Oeps inderdaad. Moet http://www.arachnoid.com/lutusp/cgi.html zijn.

[daaf258]

Op maandag 01 juli 2002 10:53 schreef drm het volgende:

Nog in voor graphics, daaf? Krijg je ook een credit

_{daaf heeft echt geprobeerd hele draad te lezen (bijna gelukt )}

Ja is goed drm ik wil wel wat proberen maar mis nog wat richtlijnen. En ik weet niet of die al vastgelegd zijn of dat daar verder afspraken over gemaakt zijn.

1. Wat moet de afmeting worden van een unit (in pixels)?
2. Hoeveel bits kleur worden er gebruikt (32)?
3. Wat voor formaat moeten de de plaatjes (units) worden opgeslagen?
4. Moeten ze geanimeerd zijn (gifjes)?
5. Welke setting, gaan we voor starcraft setting of voor een warcraft, zelf verzonnen, fantasy, realisme enz.
6. En welke "view" nemen we. Zo van "ik kijk er recht bovenop-view" (top-down view) of een isometrische view, ^{of 3d}

Nogal riegelreuze beslissingen dus als je er een mening over denkt te hebben...

En is er al iemand anders bezig met units maken of interface oid??.

Het kan zijn dat hier al meer over bekent is maar ik val een beetje middenin dit topic.

[Bosmonster]

Uit mijn vorige berichtgeving zou nog blijken dat ik weinig tijd had door gedwongen ontslagen binnen het bedrijf (waardoor er meer werk mij kant op kwam).

Dit is nu omgezet in zeeen van tijd... als je begrijp wat ik bedoel

[Verwijderd]

Op maandag 01 juli 2002 20:52 schreef Bosmonster het volgende:
Uit mijn vorige berichtgeving zou nog blijken dat ik weinig tijd had door gedwongen ontslagen binnen het bedrijf (waardoor er meer werk mij kant op kwam).

Dit is nu omgezet in zeeen van tijd... als je begrijp wat ik bedoel

Zelf gefired? Vakantie opgenomen? Zelf ontslag genomen? Toch geen ontslagen gevallen?

Oftewel: geen idee wat je bedoelt

[Bosmonster]

Op maandag 01 juli 2002 21:14 schreef dannydude het volgende:

[..]

Zelf gefired? Vakantie opgenomen? Zelf ontslag genomen? Toch geen ontslagen gevallen?

Oftewel: geen idee wat je bedoelt

boelos faillietos

[Thijsmans]

Bosmonsterus werkelosus

[Verwijderd]

Bosmonster: Dat zuigt man.. sterkte met het zoeken van een nieuwe baan. Al iets op het oog ?

[Bosmonster]

Nog niks op het oog, ga even genieten van mn instantie-betaalde maanden zeg maar.

Maar als iemand nog wat heeft voor iemand met een afgeronde HBO Interaction Design opleiding en enkele jaren ervaring in ontwerp en programmeren in Java, PHP, databases en DHTML in regio Rotterdam, schaam je dan niet

[Verwijderd]

Op maandag 01 juli 2002 21:36 schreef Bosmonster het volgende:
Nog niks op het oog, ga even genieten van mn instantie-betaalde maanden zeg maar.

Maar als iemand nog wat heeft voor iemand met een afgeronde HBO Interaction Design opleiding en enkele jaren ervaring in ontwerp en programmeren in Java, PHP, databases en DHTML in regio Rotterdam, schaam je dan niet

Back2Front failliet .. erm.. hoe ken dat nou met zulke klanten?

Ow, sorry, ja heb je homepage opgezocht via google
http://www.xs4all.nl/~bkjh/werk.html

[prototype]

offtopic:
huh? b2f failliet, waren dat niet de lui die de muse page gemaakt hebben? (MUSE is overigens m'n favo band naast RHCP).

[Pelle]

Op maandag 01 juli 2002 23:54 schreef Gordijnstok het volgende:
Ow, sorry, ja heb je homepage opgezocht via google
http://www.xs4all.nl/~bkjh/werk.html

* Pelle denkt dat Gordijnstok mee had moeten gaan met de /13 meeting

Dan had je geweten dat die gast van die site niet Bosmonster is

[Willem]

Hou het ontopic, en hou het (voorlopig) op de grote lijnen (plan van aanpak, projectteam etc.) Alle ideeen zijn welkom, maar wat mij betreft wordt dit topic streng gemod, zodat er ook wat van terecht komt

[Bosmonster]

Precies.. weer ff ontopic Want officieel mag het nieuws namelijk nog niet naar buiten

En nee das niet mijn site, dies van een collega.

En klanten maakt niet zoveel uit. Je wordt gewaardeerd op je liquiditeiten, niet op verwachtingen en toezeggingen.

[drm]

Op maandag 01 juli 2002 19:55 schreef daaf258 het volgende:
Ja is goed drm ik wil wel wat proberen maar mis nog wat richtlijnen. En ik weet niet of die al vastgelegd zijn of dat daar verder afspraken over gemaakt zijn.

Daar zijn nog geen concrete afspraken over gemaakt. En eerlijk gezegd maakt het mij ook niet zo veel uit wat het wordt. Misschien is het zelfs wel handig(er) om een team samen te stellen wat zich puur met de grafische zooi bezig houdt... Volunteers?

_{Bosmonster: sux, m8... Hoop dat je snel weer wat vindt (of een dikke spaarpot hebt gemaakt )}

[Verwijderd]

Op dinsdag 02 juli 2002 08:16 schreef Bosmonster het volgende:
Precies.. weer ff ontopic Want officieel mag het nieuws namelijk nog niet naar buiten

En nee das niet mijn site, dies van een collega.

En klanten maakt niet zoveel uit. Je wordt gewaardeerd op je liquiditeiten, niet op verwachtingen en toezeggingen.

Bosmonster, is het dan wel zo handig om het hier neer te zetten? Ik bedoel, er zitten hier niet alleen maar nerdz met een hartje voor internep....tegenwoordig hebben de nieuwsbronnen deze plek ook ondekt, om nog maar te zwijgen over de plek waar ik werk.... (neej, ik heb nix gezegd, ik ben niet zo'n klootzak.

[drm]

_{ontopic plz}

[Juup]

Op maandag 01 juli 2002 19:55 schreef daaf258 het volgende:
Ja is goed drm ik wil wel wat proberen maar mis nog wat richtlijnen. En ik weet niet of die al vastgelegd zijn of dat daar verder afspraken over gemaakt zijn.

1. Wat moet de afmeting worden van een unit (in pixels)?
2. Hoeveel bits kleur worden er gebruikt (32)?
3. Wat voor formaat moeten de de plaatjes (units) worden opgeslagen?
4. Moeten ze geanimeerd zijn (gifjes)?
5. Welke setting, gaan we voor starcraft setting of voor een warcraft, zelf verzonnen, fantasy, realisme enz.
6. En welke "view" nemen we. Zo van "ik kijk er recht bovenop-view" (top-down view) of een isometrische view, ^{of 3d}

Nogal riegelreuze beslissingen dus als je er een mening over denkt te hebben...

En is er al iemand anders bezig met units maken of interface oid??.

Het kan zijn dat hier al meer over bekent is maar ik val een beetje middenin dit topic.

1. 32 x 32 pixels ?
2. 32bits kleur
3. png (full alpha channel (Mozilla ondersteunt het!) )
4. Nee, 5 plaatjes voor alle kanten (en dan allemaal spiegelen) geloof ik. Je doet dus alleen het eerste quadrant (0°, 22.5°, 45°, 67.5°, 90°) 16 verschillende plaatjes.
5. Starcraft Setting
6. Isometrisch

Dit is voor zover ik uit deze thread heb opgemaakt en er zelf bij heb verzonnen

[Verwijderd]

Op dinsdag 02 juli 2002 12:27 schreef Jaaap het volgende:

1. 32 x 32 pixels ?

Zou kunnen, dat betekent dat een unit onderin het plaatje moet komen, en door het isometrische perspectief kun je ook enige hoogte van een unit krijgen (woordspeling )

2. 32bits kleur
3. png

Wacht even... Ik zou eerder voor .gif gaan, omdat je met .png niet aan transparantie kunt beginnen wegens slechte ondersteuning door Microsoft. Dan kom je dus op 24bit indexed color, vanwege het gif formaat.

4. Nee, 5 plaatjes voor alle kanten (en dan allemaal spiegelen) geloof ik. Je doet dus alleen het eerste quadrant (0°, 22.5°, 45°, 67.5°, 90°)

Eerder (0°, 45°, 90°, 135°, 180°) lijkt me. En dan dus 45, 90 en 135 spiegelen, en ook opslaan, zodat er wel 8 plaatjes zijn. Dat is voorlopig genoeg om een bij de richting passend plaatje te gebruiken. Vanuit elk vakje kun je naar 8 andere vakjes.

5. Starcraft Setting
6. Isometrisch

Ik denk dat het pixelneuk perspectief wel goed is, datbetekent meteen dat mensen die willen pixelneuken in ieder geval wat gebouwtjes zouden kunnen maken. Over afmetingen moet misschien nog gediscussieerd worden.

Dit is voor zover ik uit deze thread heb opgemaakt en er zelf bij heb verzonnen

Ik heb nog even wat discussiepuntjes toegevoegd

[Juup]

Op dinsdag 02 juli 2002 12:39 schreef Cheatah het volgende:
Wacht even... Ik zou eerder voor .gif gaan, omdat je met .png niet aan transparantie kunt beginnen wegens slechte ondersteuning door Microsoft. Dan kom je dus op 24bit indexed color, vanwege het gif formaat.

IE ondersteunt wel enkelvoudige transparantie in png, zelfde als gif dus. png is echter beter ivm meer dan 256 verschillende kleuren.

Eerder (0°, 45°, 90°, 135°, 180°) lijkt me. En dan dus 45, 90 en 135 spiegelen, en ook opslaan, zodat er wel 8 plaatjes zijn. Dat is voorlopig genoeg om een bij de richting passend plaatje te gebruiken. Vanuit elk vakje kun je naar 8 andere vakjes.

Huh? Als je (0°, 22.5°, 45°, 67.5°, 90°) hebt en je spiegelt alles verticaal en/of horizontaal, dan heb je 16 verschillende perspectieven. Hmmm wacht, dat spiegelen werkt niet in isometrisch perspectief. Wie had dat bedacht? We moeten echt 16 verschillende plaatjes hebben.

[Clay]

Ik denk dat de units gewoon animated gifjes moeten worden. hoe moet een "marine" anders lopen? Verder hebben verschillende units verschillende maten, dat mag wat mij betreft dus ook fysiek in het plaatje verschillen.

het lijkt mij dus handiger een "pixels in 1 meter" af te spreken.

[Verwijderd]

Alleen Mozilla is geen optie vanwege de nog steeds aanwezige SetTimeOut en SetInterval bugs

[Juup]

Op dinsdag 02 juli 2002 12:49 schreef Clay het volgende:
Ik denk dat de units gewoon animated gifjes moeten worden. hoe moet een "marine" anders lopen? Verder hebben verschillende units verschillende maten, dat mag wat mij betreft dus ook fysiek in het plaatje verschillen.

En hoe ga je die animatie 'aanzetten' op het moment dat die unit begint met lopen?

het lijkt mij dus handiger een "pixels in 1 meter" af te spreken.

Hmmmzzz.... je hebt een punt. Je kunt ook zeggen: basiseenheid is 32pixels voor een 'normale' unit (bv een marine) een goliath is dan 2 basisunits ofzo

[Juup]

Volgens mij komt het er op neer dat je 16 static plaatjes per unit nodig hebt voor stilstaande units en nog eens een buts animated plaatjes voor moving units.

Dat worden me een grote partij plaatjes.

[Bosmonster]

Op dinsdag 02 juli 2002 12:39 schreef Cheatah het volgende:

Wacht even... Ik zou eerder voor .gif gaan, omdat je met .png niet aan transparantie kunt beginnen wegens slechte ondersteuning door Microsoft. Dan kom je dus op 24bit indexed color, vanwege het gif formaat.
[..]

[mierenneukmode]

8bit indexed color bedoel je

[Woudloper]

Jaaap:
En hoe ga je die animatie 'aanzetten' op het moment dat die unit begint met lopen?

dat is niet zo heel erg moeilijk... Als de unit beweegt dan moet deze het animated plaatje laten zien...

[Pelle]

Op dinsdag 02 juli 2002 13:23 schreef Bosmonster het volgende:
8bit indexed color bedoel je

Een gif kan max 8bit aan verschillende kleuren bevatten ja, maar die kleuren komen uit een 24bit pallet
En elk gifje mag z'n eigen pallet hebben neem ik aan, dus dan kom je toch uit op 24bit indexed color

[drm]

Jaaap:
En hoe ga je die animatie 'aanzetten' op het moment dat die unit begint met lopen?

Dat lijkt me nou niet het grootste probleem

Ik denk dat Clay idd wel een goed punt heeft met x pixels is 1 meter... Ik denk zoiets van 12 pixels is 1 meter, ofzo?

_edit:

Pelle:
Een gif kan max 8bit aan verschillende kleuren bevatten ja, maar die kleuren komen uit een 24bit pallet
En elk gifje mag z'n eigen pallet hebben neem ik aan, dus dan kom je toch uit op 24bit indexed color

Je hebt maximaal 8 bits (256 plekkies in het palet) aan een kleurenindex. Waar die kleuren vandaan komen maakt niet uit. Dat die kleuren vervolgens gebaseerd zijn op een 24bits palet is een ander verhaal.

Oftewel, het is 8bits indexed color.
^{</ubermiereneukerij :D>}

[Verwijderd]

Op dinsdag 02 juli 2002 13:23 schreef Bosmonster het volgende:

8bit indexed color bedoel je

[slightly offopic]
Tricky one, aan de ene kant moet elke kleur worden gedefinieerd met 24 bits, maar elke kleur wordt gekoppeld aan een 8-bit 'identifier' (of hoe moet je het anders noemen)

Per pixel zijn 8 bits nodig om de kleur ervan te beschrijven, maar het zijn wel degelijk 24 bit kleuren die je uiteindelijk ziet.

Maar als je kijkt naar de definitie, dan heb jij waarschijnlijk gelijk

[Pelle]

* Pelle is het met Cheatah eens
Uiteindelijk is het het naampje dat je eraan geeft; als iedereen het er maar over eens is dat je max 256 van de 16777216 kleuren kunt gebruiken, dan gaan we nu weer écht ontopic

[drm]

* drm is het niet met Pelle en Cheatah eens.

Maar we gingen ontopic, hm?

[Tim]

Op dinsdag 02 juli 2002 12:45 schreef Jaaap het volgende:
Huh? Als je (0°, 22.5°, 45°, 67.5°, 90°) hebt en je spiegelt alles verticaal en/of horizontaal, dan heb je 16 verschillende perspectieven. Hmmm wacht, dat spiegelen werkt niet in isometrisch perspectief. Wie had dat bedacht? We moeten echt 16 verschillende plaatjes hebben.

Spiegelen werkt wel in isometrisch perspectief, maar volgens mijn is IE de enige browser die een plaatje kan spiegelen

[drm]

Timpie:
Spiegelen werkt wel in isometrisch perspectief, maar volgens mijn is IE de enige browser die een plaatje kan spiegelen

't Lijkt mij ook niet dat de browser voor ons moet gaan spiegelen

[Juup]

Op dinsdag 02 juli 2002 14:25 schreef Timpie het volgende:
Spiegelen werkt wel in isometrisch perspectief, maar volgens mijn is IE de enige browser die een plaatje kan spiegelen

Neem in gedachten een vliegtuigje met bovenkant boven. Als je die (verticaal) spiegelt over een horizontale lijn dan komt de bovenkant onder te liggen/staan.

Same story voor links/rechts bij horizontaal speigelen

[Juup]

Op dinsdag 02 juli 2002 14:35 schreef drm het volgende:
't Lijkt mij ook niet dat de browser voor ons moet gaan spiegelen

Jawel dan hoef je veel minder plaatjes (=kB) in te laden.

[Limhes]

Op dinsdag 02 juli 2002 16:08 schreef Jaaap het volgende:

[..]

Jawel dan hoef je veel minder plaatjes (=kB) in te laden.

De discussie daarover is al gevoerd volgens mij. Het kwam erop neer dat men geen filters oid. wil gebruiken omdat de afspraak is het spel in DHTML te maken.

[daaf258]

Op dinsdag 02 juli 2002 12:27 schreef Jaaap het volgende:

1. 32 x 32 pixels ?
2. 32bits kleur
3. png (full alpha channel (Mozilla ondersteunt het!) )

1.32*32 pixels ok en voor groter units 64*32? en supergrote 64*64? of nog groter?

2.Ik denk gif dus 256 kleuren uit 24-bit pallet.

de rest is wel duidelijk.

Op dinsdag 02 juli 2002 13:30 schreef drm het volgende:

Ik denk dat Clay idd wel een goed punt heeft met x pixels is 1 meter... Ik denk zoiets van 12 pixels is 1 meter, ofzo?

Over schaal. Ik ben geen voorstander van zoveel (12) pixels is 1 Meter.
Tenminste als dit inhoud dat er op een preciese schaal gewerkt gaat worden. Zo van mensje is 2 meter dus 24 pixels.
En gebouwtje dan?

Voorbeeldje in starcraft, als dat de definitieve setting word, is er weinig aan realistische schaal gedaan. Een groepje van zeg 12 units is net zo groot als een gebouw. Dus wat dat schaal betreft vind ik dat systeem van starcraft (en warcraft) niet zo gek.

Als dit niet de bedoeling is, wat wil je dan met die maat gaan doen?

Even over animaties, hoeveel frames mag een animatie worden dan?

[Clay]

Starcraft doet zelf idd ook niet al te realistisch aan schaal. zo'n marine zou met moeite in een siege tank kunnen wat dat betreft kunnen we nog ff verder ruzien dus

En als die 24 bij 24 wordt zou ik me over het aantal frames niet teveel zorgen maken. dat kan nooit een grote gif worden. voor lopen zouden 2 frames eigenlijk genoeg moeten zijn je hebt immers 2 benen. de rest van de images van een unit zorgen er dan wel voor dat het geen kaal geheel lijkt.

[daaf258]

_{het is maar een simpel probeersel van grondunit. check de box met ammo onder zijn linkerarm}



Maar zoiets moet het worden?

/edit Pelle
linkje gefix0red

[daaf258]

grr wou dat net zelf doen

Beetje laat i guess

edit:

hahah lekker toch nog editten nu bedankt Pelle

[Juup]

Zorg er in ieder geval in de code voor dat een unit willekeurige afmetingen mag hebben (ook niet vierkant)

Daaf258: Transparantie?

[Woudloper]

Jaaap:
Zorg er in ieder geval in de code voor dat een unit willekeurige afmetingen mag hebben (ook niet vierkant)

Dit kan toch eenvoudig worden gedaan door allereerst voor de Units standaard properties te bedenken. In dit geval kan je dan dus denken aan H/W (Heigt/Width).

Daarnaast zijn er nog wel meer opties, maar dit gaat al een beetje lijken op een begin van een object model voor de Units en dat met nog maar twee geïndentificeerde properties...

<sub>Oei... Ik loop veel en veel te hard van stapel, komt waarschijnlijk doordat ik nog maar 1,5 dag moet werken en dan vakantie..

Edit: stomme spelfout, zie hieronder</sub>

[daaf258]

Op woensdag 03 juli 2002 12:04 schreef Jaaap het volgende:
Daaf258: Transparantie?

Gisteravond laat eh
Maar ik heb er ook een met transparantie.

[drm]

daaf258:
Ik ben geen voorstander van zoveel (12) pixels is 1 Meter.
[en het "waarom"]

Is ook wel zo. Da's ook een van de redenen dat ik geen zin heb me te bemoeien met grafische zooi

Moet alleen wel zeggen dat ik je unit niet de meest duidelijke vind. Ik denk dat je er iets teveel detail in hebt willen gooien.

[Juup]

Op woensdag 03 juli 2002 12:08 schreef Woudloper het volgende:
In dit geval kan je dan dus denken aan H/W (Heigt/Weight).

Bedoel je Height / Width?

[Clay]

* schop

Ik heb een testcase gemaakt voor een isometrische "engine". 2 Tables die over elkaar heenliggen om de tiles op elkaar aan te laten sluiten, en het geheel in een div die beweegt. De buitenste tiles komen nooit helemaal in beeld om een volledig heeld te houden, ala:


(stippellijntje dus)

Voorbeeld staat hier:
http://www.xs4all.nl/~peterned/got/snowstorm/
Plaatjes worden niet gepreload, maar da's wel ff leuk eigenlijk om het effect te zien. De muismovement zo is natuurlijk alleen maar tijdelijk.

[Bosmonster]

Ik moet zeggen.. ik ben erg onder de indruk Clay! Vooral over de natuurlijke manier waarop het beeld meeschuift met je muis. Iets wat ik nog nooit in een profi RTS gezien heb.

Ik weet niet in hoeverre die beweging ook mogelijk is met een groot speelveld, maar denk dat we die der maar in moeten houden

[Clay]

hmz weenie als alle puzzelstukken in elkaar gaan vallen zal het uiteindelijk best wel een zware game worden. Dat scrollen is dan het makkelijkste om op te "bezuinigen" of iig als optionele instelling aan te bieden oid.

[Juup]

Zijn er mensen die al hebben gemaakt? Of textures?

[Thijsmans]

Op dinsdag 09 juli 2002 11:25 schreef Jaaap het volgende:
Zijn er mensen die al hebben gemaakt? Of textures?

al hebben gemaakt wat al hebben gemaakt?

[Clay]

Er zijn denk ik 2 dingen waar nu op gefocussed moet gaan worden.

• Tile based "engine"
  waarbij dus een map gemaakt kan worden met een "editor". je hebt bijvoorbeeld het type "verhoogde grond", als je op een tile klikt maakt ie dat met de verhoogde graphics, maakt de aangrenzende velden "passend" qua graphics, en stelt per tile in waar je wel of niet lopen kan.
  Daarbij hoort dan natuurlijk dat een x en y coordinaat op de map de bijbehorende tile teruggeeft, en dat een tile zijn buren kent.
• Units
  Een basis unit die over de map kan lopen, afhankelijk van de tile wel of niet ergens komen kan, en dan het path-algoritme.

Als dat werkt zijn we ook al een heel end.

Als soort van "dream on" wens lijkt het me trouwens wel vet om uiteindelijk een editor te hebben die een map in XML uitpoept en wegschrijft, zodat het spel een level ook in kan lezen als XML. Een level zal hoe dan ook op een bepaalde manier opgeslagen moeten worden. XML lijkt me daar uitstekend voor.

[Bosmonster]

Voordat we aan een tile-engine beginnen eerst maar ff een level-file-format vaststellen?

Kan al zo simpel zijn als een enorme Array die je declareert in een losse JS file ofzo. Maar liever een los Level object, met bijbehorende classes.

[drm]

waarom idd daar geen XML voor nemen?

_edit:
misschien een freak die zin heeft om er een DTD voor te verzinnen?

[Verwijderd]

Op dinsdag 09 juli 2002 15:36 schreef drm het volgende:
misschien een freak die zin heeft om er een DTD voor te verzinnen?

hmm deze freak wil best helpen, zal alleen wat meer info moeten hebben voordat ik daar aan begin... en hulp veel hulp

[Bosmonster]

Op dinsdag 09 juli 2002 15:36 schreef drm het volgende:
waarom idd daar geen XML voor nemen?

_edit:
misschien een freak die zin heeft om er een DTD voor te verzinnen?

XML is wel stoer.. maar.. Het inlezen/parsen van een XML file zal met Javascript gok ik 10x zolang duren als het simpelweg embedden van een JS-file met Object-definitie.

[Verwijderd]

En javascript is natuurlijk stoerder. Ik heb een unit die een in-memory javascript variabele weer als source (tekst) uitpoept. Dus:

code:

var o=new Object();
o.x=12;
o.y=13;

alert( toSource(o) );
//en die zegt: "{x:12, y:12}"

Een iets oudere versie staat op mijn site (er zijn een aantal bug-fixes op geweest).

[drm]

Bosmonster:
XML is wel stoer.. maar.. Het inlezen/parsen van een XML file zal met Javascript gok ik 10x zolang duren als het simpelweg embedden van een JS-file met Object-definitie.

Tja, maar dat (inlezen,parsen) hoeft per spelletje maar 1x te gebeuren, lijkt mij En 't is de meest flexibele oplossing, imo. Op den duur zal je daar toch wel naartoe willen.

[Verwijderd]

Op woensdag 10 juli 2002 08:54 schreef drm het volgende:

[..]

Tja, maar dat (inlezen,parsen) hoeft per spelletje maar 1x te gebeuren, lijkt mij En 't is de meest flexibele oplossing, imo. Op den duur zal je daar toch wel naartoe willen.

Waarom niet met XSLT de XML transformeren naar een JS dataset?

[drm]

Blues:
Waarom niet met XSLT de XML transformeren naar een JS dataset?

* drm vraagt zich af hoe men die JS gaat uitvoeren, dan, zonder serversided zaken

[Juup]

Op woensdag 10 juli 2002 11:30 schreef drm het volgende:
* drm vraagt zich af hoe men die JS gaat uitvoeren, dan, zonder serversided zaken

De client voert die .js uit.

[André]

XML is inderdaad mogelijk, maar de vraag is of het nodig is.

Moet de data uitwisselbaar zijn met andere applicaties in een standaardformaat? Dat is waarom oorspronkelijk XML ontworpen is.

Ik denk niet dat dat nodig is, plus het vertraagd de zooi ook enorm. Ook al is die vertraging alleen maar in het begin, waar snelheid gewonnen kan worden moeten we dat doen.

[drm]

Jaaap:
De client voert die .js uit.

Nee, ik bedoel dat de XML eerst getransformeerd moet worden met XSLT. Hoe ga je de getransformeerde data (die dan dus JS code is) uitvoeren?

[Clay]

Wat is nou mooier en handiger, een js bestand met:

code:

var startPositions = [
  [1034, 304],
  [100, 1590]
]

var gameUnits = [
   [x,y, type],
   ...
]

enz. grote lap globale vars string en int data

of xml ala(voor het idee):

code:

<level>
   <title>Orions belt</title>
   <players>2</players>

   <entities>
     <building>
      <type>Siege tank</type>
      ....
     </building>

     <unit>
      <type>marine</type>
      ...
     </unit>

     ...

   </entities>

</level>

Ik zie een js bestand als level dus niet zo zitten eingelijk.

[André]

Op woensdag 10 juli 2002 13:13 schreef drm het volgende:

[..]

Nee, ik bedoel dat de XML eerst getransformeerd moet worden met XSLT. Hoe ga je de getransformeerde data (die dan dus JS code is) uitvoeren?

XML:

code:

<unit>
  <strength>10</strength>
  <speed>20</speed>
</unit>

Na transformatie:

code:

Monster = new Unit(10, 20);

Die dit object gebruikt:

code:

function Unit(st, sp)
{
  this.strength = st;
  this.speed = sp;
}

Je krijgt na transformatie kant en klare objecten die je kunt gebruiken.

[Verwijderd]

eens met Clay, maar ik denk dat je echt alles eerst van te voren heel duidelijk moet hebben, voordat je aan XML begint te denken, dus eerst een werkend level, die dan vertalen naar XML (in een DTD.. misschien) en dan kijken wat het beste resultaat oplevert (JS of XML).

Is de XML versie iets trager, in het begin, maar komt het de werkbaarheid ten goede, ga dan voor die versie, wordt het echter te traag, dan is alleen een JS versie een optie.

[LuCarD]

Op woensdag 10 juli 2002 13:26 schreef Clay het volgende:
Wat is nou mooier en handiger, een js bestand met:

code:

var startPositions = [
  [1034, 304],
  [100, 1590]
]

var gameUnits = [
   [x,y, type],
   ...
]

enz. grote lap globale vars string en int data

of xml ala(voor het idee):

code:

<level>
   <title>Orions belt</title>
   <players>2</players>

   <entities>
     <building>
      <type>Siege tank</type>
      ....
     </building>

     <unit>
      <type>marine</type>
      ...
     </unit>

     ...

   </entities>

</level>

Ik zie een js bestand als level dus niet zo zitten eingelijk.

Helemaal mee eens,

Je foutcontrole word ook een stuk stabieler, je kan met XML en DTD een heel nette controle maken.

En snelheid is niet zo'n probleem, aangezien je er alleen last van hebt tijdens het laden. En niet tijdens het spelen.

[André]

Op woensdag 10 juli 2002 13:39 schreef LuCarD het volgende:

[..]

En snelheid is niet zo'n probleem, aangezien je er alleen last van hebt tijdens het laden. En niet tijdens het spelen.

Het is toch ook niet de bedoeling om hem online te kunnen spelen maar alleen maar lokaal?

Dan hoef je niet op de kb's te letten, en is de snelheid/traagheid niet zo'n probleem.

* André denkt inderdaad "XML roels bigtime"

[LuCarD]

Op woensdag 10 juli 2002 13:50 schreef Yogho het volgende:

[..]

Het is toch ook niet de bedoeling om hem online te kunnen spelen maar alleen maar lokaal?

Dan hoef je niet op de kb's te letten, en is de snelheid/traagheid niet zo'n probleem.

* LuCarD denkt inderdaad "XML roels bigtime"

Tijdens laden bedoel ik mee het opstarten van het spel, hij hoeft tenslote maar 1 keer worden geparset naar JS objecten.

En dat kost tijd...

[Bosmonster]

Op woensdag 10 juli 2002 13:26 schreef Clay het volgende:
Wat is nou mooier en handiger, een js bestand met:

code:

var startPositions = [
  [1034, 304],
  [100, 1590]
]

var gameUnits = [
   [x,y, type],
   ...
]

enz. grote lap globale vars string en int data

of xml ala(voor het idee):

code:

<level>
   <title>Orions belt</title>
   <players>2</players>

   <entities>
     <building>
      <type>Siege tank</type>
      ....
     </building>

     <unit>
      <type>marine</type>
      ...
     </unit>

     ...

   </entities>

</level>

Ik zie een js bestand als level dus niet zo zitten eingelijk.

Zoals jij het als eerste neerzet is ook niet echt vergelijkbaar met je tweede natuurlijk Levels worden voor echte games ook in een eigen soort scripttaal neergezet en niet via XML of ander simpel datatype. Simpelweg omdat je dan ook niet flexibel genoeg kan zijn. Denk meer aan zoiets:

code:

GlobalGame.levels.push( myLvl = new Level() );
myLvl.title = "Kick the fuckers!";
myLvl.useMap( new MapFile( "mapfile3.js" ) );
myLvl.addUnit( TANK1, 100, 150 );
myLvl.addUnit( INFANTRY, 134, 150 );
etc...

[Clay]

daar zit wel wat in. Dat staat ook custom-level scripting toe. In level2 van Operation 043 (platformgame) heb ik ook levels in losse js'jes gedefineerd, en juist daardoor kon ik custom dingen doen, zoals die elevator "waaier" zo'n beetje aan het einde van level 2.

[drm]

Yogho:
XML:

code:

<unit>
  <strength>10</strength>
  <speed>20</speed>
</unit>

Na transformatie:

code:

Monster = new Unit(10, 20);

Die dit object gebruikt:

code:

function Unit(st, sp)
{
  this.strength = st;
  this.speed = sp;
}

Je krijgt na transformatie kant en klare objecten die je kunt gebruiken.

Dat begrijp ik wel, maar hoe voer je die JS code nou uit, want 't is data en geen code en eval is vies
^</flauw>

[crisp]

Ik ben vandaag ook even aan het rommelen geweest met DOM, eigen objecten en collision detection; hier het resultaat
Misschien ziet er nog wat bruikbaars in, en zoniet dan heb ik in elk geval weer een hoop bijgeleerd

[Verwijderd]

Nadeel van jouw code is dat wanneer er veel gezichtjes zijn ze duidelijk langzamer bewegen. Er zal dus een efficientere code gevonden moeten worden wil je massive attacks kunnen toestaan in Snowstorm. Verder ziet het er wel grappig uit...

[mbravenboer]

Bosmonster: Levels worden voor echte games ook in een eigen soort scripttaal neergezet en niet via XML of ander simpel datatype. Simpelweg omdat je dan ook niet flexibel genoeg kan zijn.

XML is geen simpel datatype, maar een generiek datatype. Een abstract data-type voor alle vormen van tree-achtige data. Je moet XML ook niet tegenover andere talen zetten, zoals bijvoorbeeld JavaScript of andere scripting talen.

XML is namelijk een soort boom-vormige representatie van een stukje data. Talen als Javascript worden ingelezen door deze te parsen, waarbij de parser een boom-vormige representatie van een stukje code oplevert. Zo'n echte syntax wordt ook wel vaak een concrete syntax genoemd. De boom-structuur een abstracte syntax en het resultaat noemt met een AST: abstract suntax tree.

Klein voorbeeldje: 4 + 5 kan je als volgt in XML vorm representeren:

code:

<plus>
  <int-const>4</int-const>
  <int-const>5</int-const>
</plus>

Nog een klein voorbeeldje: 4 + 5 * 6 kan je als volgt in XML vorm representeren:

code:

<plus>
  <int-const>4</int-const>
  <multiply>
    <int-const>5</int-const>
    <int-const>6</int-const>
  </multiply>
</plus>

Dit vraagt natuurlijk ontzettend veel code in vergelijking met de concrete syntax: 4 + 5 * 6. Deze XML geeft echter wel een goed idee van hoe een stukje code uit een parser komt.

XML is daarom in feite equivalent aan een concrete-syntax: bij elke concrete syntax (in ieder geval van programmeertalen) kan je een grammatica maken. Deze grammatica beschrijft de taal. De parser kan een stukje concrete syntax omzetten naar de abstracte-syntax: de boom.

Denk meer aan zoiets:

code:

GlobalGame.levels.push( myLvl = new Level() );
myLvl.title = "Kick the fuckers!";
myLvl.useMap( new MapFile( "mapfile3.js" ) );
myLvl.addUnit( TANK1, 100, 150 );
myLvl.addUnit( INFANTRY, 134, 150 );
etc...

Ook dit kan je dus prima in abstracte syntax beschrijven en dus ook in XML. Het probleem is alleen dat dit erg veel XML gaat opleveren. Zo is het bijvoorbeeld ook mogelijk om een stukje Java code om te zetten naar XML en om at runtime een Java object naar XML te serializeren.

Het grote voordeel van XML is dat je in feite bezig bent om abstract syntax bomen uit te wisselen. Hierdoor werken applicaties direct op deze abstracte syntax en hoeft er dus geen parser geschreven te worden: de abstracte syntax hoeft alleen maar geinterpreteerd te worden.

In dit geval is dit voordeel wat vaag als je de XML weer gaat omzetten naar Javascript: als het XML formaat echt gelijk is aan iets Javascript achtigs, ben je in feite bezig met een overgang van abstracte naar concrete syntax, waar je niet veel mee opschiet. In dat geval kan je dus vanwege de verbositeit van XML wellicht beter kiezen voor Javascript.

Als het taaltje echter toch wel liever anders moet worden dan Javascript is XML nog wel een hele goede optie. Het XML formaat wat je kiest kan dan vertaald worden naar Javascript constructies, waarbij het niet een simpele omzetting naar concrete syntax is. Je taaltje beschrijft dan echt de data die je nodig hebt en is geen pure Javascript code. Hier kan je ook allerlei handige functionaliteit aan toevoegen.

Het voordeel van XML tov Javascript is in deze situatie wellicht ook dat de XML makkelijk toegepast kan worden in een andere situatie: als je Javascript 'data' hebt, zit je min of meer 'opgesloten' in Javascript. Een eigen XML fromaat staat daar volledig los van.

Dit verhaal is natuurlijk zeer onvolledig er valt veel meer te vertellen over XML en de relatie met een concrete syntax, maar ik hoop dat ik hiermee iets kan bijdragen aan een keuze die jullie moeten maken .

[Verwijderd]

Op zaterdag 13 juli 2002 13:51 schreef mbravenboer oa het volgende:
Dit verhaal is natuurlijk zeer onvolledig er valt veel meer te vertellen over XML en de relatie met een concrete syntax, maar ik hoop dat ik hiermee iets kan bijdragen aan een keuze die jullie moeten maken .

Zei hij vrolijk na minstens 1 A4'tje getypt te hebben over XML en abstracte en concrete syntax.

[crisp]

Op zaterdag 13 juli 2002 12:58 schreef dannydude het volgende:
Nadeel van jouw code is dat wanneer er veel gezichtjes zijn ze duidelijk langzamer bewegen. Er zal dus een efficientere code gevonden moeten worden wil je massive attacks kunnen toestaan in Snowstorm. Verder ziet het er wel grappig uit...

Ik denk dat mijn code juist bewijst dat interactie tussen een aantal elementen met (pixelpreciese!) collision detection heel goed mogelijk is; dit is nog maar een ruwe opzet waar nog wel wat aan gesleuteld kan worden om het sneller te maken. Ik denk dat in een spel de units een stuk minder snel zullen bewegen, waardoor meer units geen probleem is.
Ik had eerst gekozen voor variabele timers om de snelheid van de smilies te regelen samen met een richtingsvector; ik heb dat later omgezet naar een x en y verplaatsingsfactor per tijdseenheid omdat dat de berekeningen voor de nieuwe snelheid en richting na collision wat vereenvoudigde.
Ik ga de originele insteek echter ook nog eens verder uitwerken om te kijken of dat nog verschil maakt...

[Verwijderd]

Martin's betoog behoeft enkele practische vragen:

Hoe zien jullie de game-editor. Zelf met het handje inkloppen (xml, javascript, romanvorm maakt niet uit) of een grafische game-editor maken.

Indien ja, is die editor dan ook een .html-pagina? Wel het mooist, maar je blijft zitten met het bewaren van het level.

Als je XML wilt gebruiken, wil je het MSXML object gebruiken of een javascript xml parser (ze bestaan:7), of ga je die XML transformeren naar javascript. In dat laatste geval heb je weer problemen met de editor, die het level dan weer als XML moet wegschrijven.

Op woensdag 10 juli 2002 17:16 schreef drm het volgende:
Dat begrijp ik wel, maar hoe voer je die JS code nou uit, want 't is data en geen code en eval is vies
^</flauw>

Is het volgende wellicht een idee

code:

<script src="level.js" type="text/javascript"></script>
<script src="engine.js" type="text/javascript"></script>

[crisp]

Op zaterdag 13 juli 2002 23:19 schreef Doekman het volgende:
Martin's betoog behoeft enkele practische vragen:

...

Als je XML wilt gebruiken, wil je het MSXML object gebruiken of een javascript xml parser (ze bestaan:7), of ga je die XML transformeren naar javascript. In dat laatste geval heb je weer problemen met de editor, die het level dan weer als XML moet wegschrijven.
[..]

Ik heb zelf al een cross-browser XML loader liggen (voor IE wordt dan het MSXML object gebruikt, voor Moz/NS de ingebouwde XML functionaliteit. Clay was geloof ik ook bezig met een crossbrowser XML parser.
In feite is het parsen mbv javascript redelijk universeel te noemen op het moment dat je de handle naar het XML document reeds hebt na het inladen; de truck is om niet properties uit te vragen dmv:

code:

var prop = xmlDoc.getElementsByTagName('blaat').item(i).text;

maar via de DOM structuur:

code:

var prop = xmlDoc.getElementsByTagName('blaat').item(i).childNodes.item(0).nodeValue;

Dit werkt namelijk zowel in IE als in NS/Moz

[Bosmonster]

Op zaterdag 13 juli 2002 13:51 schreef mbravenboer het volgende:

[..] XML [..] XML [..] XML [..]

Dus? Je concludeert dat XML toch niet de handigste methode is om een flexibel levelsysteem op te zetten. Niet dat het niet KAN, maar dat je dan enorme hoeveelheden XML krijgt die het inlezen van een level een paar minuten zullen laten duren (inlezen van waarden middels DOM duurt nogal lang namelijk in JS, en dan hebben we nog niks gedaan met al die waarden...) of waarschijnlijk je browser zullen laten crashen Tis geen Java mbravenboer, maar JavaSCRIPT

[Clay]

volgens mij bedoeltie dat het suf is om de ingevoerde xml direct te vertalen naar uitvoerbaar script, maar dat het wel handig is om data in xml te voeren, en dat uit te lezen met js, ala:

code:

<unit>
 <type>marine</type>
<unit>

// parsen,

for(van i in parsedUnits) {
  new unit(parsedUnits[i].type);
}

crisp
Clay was geloof ik ook bezig met een crossbrowser XML parser

Yup, is ook gelukt nu. Er zit ook nog een extra stukje functionaliteit in die van de xml meteen een object maakt:

code:

<level>
  <name>flight of the valkyries</name>
  <entities>
    <unit>marine</unit>
    <unit>tank</unit>
    <unit>tank</unit>
  </entities>
</level>

// parser naar object:

level.name.nodeValue == "flight of the valkyries"
level.entities.unit[1].nodeValue == "tank"

Kweenie of dat handig is maar ik heb dit een keer ergens voor voor flash gemaakt en gebruikt, en nu heb ik het dus gepoort naar js.

[Verwijderd]

Ik heb op basis van de map van Clay een background editor gemaakt.

Het ging me voornamelijk om te kijken op welke tile geklikt wordt. De lichtgrijze tiles zitten nl. op de achtergrond en krijgen dus nooit een event. Ik heb dit opgelost met de good-old image-map.

De code is bagger; het gaat voornamelijk om het idee. Ik was eigenlijk niet van plan mee te helpen (geweldig idee, maar ik heb niet te veel tijd), maar ik verloor me zelf even. Het zal niet weer gebeuren

[mbravenboer]

Bosmonster: Tis geen Java mbravenboer, maar JavaSCRIPT

Grapjurk .

Ik doelde wel degelijk op Java, maar maakte daarbij inderdaad een beetje een vreemd sprongetje: voor Java zijn allerlei leuke XML serializatie libraries. Voor Javascript ligt dat toch allemaal wat lastiger.

Ik doelde er overigens inderdaad op (zoals Clay ongeveer aangaf) dat het heel aardig kan zijn om in XML de data van een level te beschrijven, maar dat het eigenlijk onzinnig complex is om in XML een Javascript beschrijving van het level te gaan beschrijven. Het klinkt allemaal misschien wat warrig, maar het is toch wel een belangrijk verschil. Javascript code is natuurlijk iets heel anders de data van een level.

Het kan heel nuttig zijn om de data die in XML is beschreven toch nog naar Javascript om te zetten via een transformatie en deze daarna gewoon uit te voeren. Het is dus niet nuttig om Javascript-in-XML om te zetten naar Javascript en daarna uit te gaan voeren. De uitwisseling in Javascript-in-XML formaat is dan eigenlijk volledig zinloos en kost alleen maar onnodig veel resources en werk.

[mbravenboer]

Waar je overigens mee uit moet kijken is dat een pure data beschrijving van je level misschien erg veel beperkingen heeft, omdat je dus nooit andere zaken kan doen dan wat mogelijk is via de data. Een volledige scripting taal biedt natuurlijk onbegrensde mogelijken, wat waarschijnlijk ook de reden is waarom de meeste games iets dergelijke gebruiken.

Je zou een level misschien op kunnen bouwen uit zowel data als scripts, maar die keuze is verder mijn zorg niet: ik kwam hier alleen maar om de voordelen, nadelen en betekenis van XML uit te leggen .

[Clay]

Op zondag 14 juli 2002 18:06 schreef Doekman het volgende:
Ik heb op basis van de map van Clay een background editor gemaakt.

Het ging me voornamelijk om te kijken op welke tile geklikt wordt. De lichtgrijze tiles zitten nl. op de achtergrond en krijgen dus nooit een event. Ik heb dit opgelost met de good-old image-map.

De code is bagger; het gaat voornamelijk om het idee. Ik was eigenlijk niet van plan mee te helpen (geweldig idee, maar ik heb niet te veel tijd), maar ik verloor me zelf even. Het zal niet weer gebeuren

vet!!

[crisp]

Ben nog even aan het sleutelen geweest aan mijn smilies, en heb de performance zo'n 50% op kunnen schroeven
Veel meer valt er niet meer uit te persen ben ik bang; collision detection is nu eenmaal vrij intensief omdat alle objecten elkaar in de gaten moeten houden. Dat wil zeggen, object 0 houd niemand in de gaten, object 1 houd object 0 in de gaten, object 2 houd object 0 en 1 in de gaten usw...
Wel heb ik met wat breaks de checks wat sneller kunnen maken, ervan uitgaande dat een collision minder vaak voorkomt dan een niet-collision.
Variabele timers hebben denk ik toch niet zoveel zin, omdat langzaam bewegende objecten dan toch ook een vaste verplaatsing hebben, en dus 'schokkerig' gaan bewegen, tenzij je de verplaatsingseenheid weer behoorlijk klein maakt, wat de intensiteit weer opdrijft wb snel bewegende objecten.
Misschien kunnen andere goeroes hier hun licht eens op laten schijnen?

[Verwijderd]

Ziet er goed uit crisp. Ik heb je code even getimed. Op mijn systeempje (Duron 700, IE6 met een superslechte videokaart) met 25 smileys neemt het verplaatsen 22% van de tijd en de collision-detection 21%.

Een optimalisatie zou kunnen zijn objecten pas te verplaatsen (tekenen) als ze in zicht zijn.

[crisp]

Op maandag 15 juli 2002 00:48 schreef Doekman het volgende:
Ziet er goed uit crisp. Ik heb je code even getimed. Op mijn systeempje (Duron 700, IE6 met een superslechte videokaart) met 25 smileys neemt het verplaatsen 22% van de tijd en de collision-detection 21%.

Een optimalisatie zou kunnen zijn objecten pas te verplaatsen (tekenen) als ze in zicht zijn.

Het nadeel is dat de tijd voor de collision detection exponentieel toeneemt bij meer smilies; ik denk dat je op jouw systeem al heel rap naar de 100% schiet als je meer dan 25 smilies neemt.
Smilies niet fysiek verplaatsen als ze niet in beeld zijn (wat hier dus niet voorkomt) betekent wel weer extra code voor het bijhouden van de viewport, maar is denk ik wel sneller dan een layer-verplaatsing.

[Clay]

Realtime collision is dan denk ik niet echt haalbaar 't is denk ik goed mogelijk dat alletwee de teams 30 tot 40 units hebben (alhoewel we die regels zelf bepalen), en dan is collision niet meer te doen, zeker niet als het spel ook nog allerlij andere zaken moet gaan bijhouden.

Ik heb zelf ook een collision test gedaan (beejte buggy), net als crisp houdt een blok de collision bij ala 1 met 2-3-4, 2 met 3-4, enz, en daarnaast is die berekening losgehaald van de move van de layer. Die move gaat op zijn beurt met "threads", waarbij 1 tread de positie van een paar layers update. 40 layers kunnen dan bijvoorbeeld 8 threads met elk 5 te updaten layers zijn.
Zo kom ik hier op een p800 tot 60 layers vrij vloeiend (niet zaligmakend) en met 90 layers (3 per thread) hangt de performance al rond de 80 a 90 %

link

Ik denk dat het dan handiger is de collision per unit niet te doen, en dan met het bewegen van groepen units gewoon een soort "wolk" van posities om het klikpunt te gebruiken.

[drm]

Clay: ["wolk"]

Is een idee, maar dat wordt wel lastig...

Stel bijvoorbeeld dat je een groep van X units (zeg, 12) van A naar B laat wandelen, en halverwege wil je een 1 uit de groep naar C laten wandelen. Dan zal deze uit de wolk gehaald moeten worden, en weer onafhankelijk collision-gedetect moeten worden (om het maar eens in mooi nederlands te zeggen...)

Als ik 't goed heb dan heb je kans dat je in je pathfinding weer op problemen stuit, namelijk, dat de groep beweegt over de kortste weg... oftewel, de unit blijft met de groep meelopen, als je begrijpt wat ik bedoel...

[Bosmonster]

Sinds wanneer is collision detection zo belangrijk bij een tile-based engine?? Je moved toch gewoon van tile naar tile? Is tile bezet, kijk dan naar andere weg (voer pathfinding opnieuw uit).

Sterker nog in je pathfinding kun je de bezette tiles (units) gewoon in de map meenemen.

[Pelle]

Op maandag 15 juli 2002 19:04 schreef Bosmonster het volgende:
Sinds wanneer is collision detection zo belangrijk bij een tile-based engine?? Je moved toch gewoon van tile naar tile? Is tile bezet, kijk dan naar andere weg (voer pathfinding opnieuw uit).

Sterker nog in je pathfinding kun je de bezette tiles (units) gewoon in de map meenemen.

Inderdaad, dat lijkt mij ook. Het maakt niet zoveel uit of 2 units elkaar onderweg van de ene naar de andere tile kruisen; zolang ze niet fysiek op een tile zijn aangekomen maakt dat niks uit.
Je hoeft alleen maar bij te houden welke tiles bezet zijn (of voor hoeveel procent). Een siegetank neemt een hele tile in beslag, maar op diezelfde ruimte kan een zergling met 3 of 4 broertjes en zusjes de boel onveilig maken.