[DHTML] Project "Snowstorm"

[crisp]

* crisp moet toch eens starcraft gaan spelen
Ik heb namelijk geen idee wat voor een spel dat eigenlijk is; ben meer van het shoot-um-up type dan van de RPG games.
Collision detection is echter wel een interessant onderwerp; ik zit op dit moment te denken aan een constructie waarbij de objecten zelf geen detection doen, maar een apart proces de afstanden tot de objecten in de gaten houd, en collision events triggered...

[Bosmonster]

Op maandag 15 juli 2002 23:06 schreef crisp het volgende:
* crisp moet toch eens starcraft gaan spelen
Ik heb namelijk geen idee wat voor een spel dat eigenlijk is; ben meer van het shoot-um-up type dan van de RPG games.
Collision detection is echter wel een interessant onderwerp; ik zit op dit moment te denken aan een constructie waarbij de objecten zelf geen detection doen, maar een apart proces de afstanden tot de objecten in de gaten houd, en collision events triggered...

DHTML collision detection (hoewel dan even offtopic voor de tile-based engine) zou je volgens mij efficienter kunnen maken door eerst gewoon de layer collisions te detecten (mooie rechthoeken), en vervolgens pas op inhoud te kijken (alternatieve vormen).

Op deze manier hoef je niet per-pixel detection te doen constant. Maar tis een wild-guess... heb niet naar je code gekeken, misschien dat het al zo in elkaar zit

[crisp]

Op maandag 15 juli 2002 23:13 schreef Bosmonster het volgende:

[..]

DHTML collision detection (hoewel dan even offtopic voor de tile-based engine) zou je volgens mij efficienter kunnen maken door eerst gewoon de layer collisions te detecten (mooie rechthoeken), en vervolgens pas op inhoud te kijken (alternatieve vormen).

Op deze manier hoef je niet per-pixel detection te doen constant. Maar tis een wild-guess... heb niet naar je code gekeken, misschien dat het al zo in elkaar zit

Zit al zo in elkaar
Aangezien het hier om gelijksoortige vormen gaat, check ik alleen de absolute afstand tussen de top-left coordinaten. Dit is voldoende voor square-detection, voor de ronde vorm gooi ik er nog een radius-check overheen

[Annie]

Op maandag 15 juli 2002 23:06 schreef crisp het volgende:
* crisp moet toch eens starcraft gaan spelen

zoals al eerder gezegd: shame on you

Op maandag 15 juli 2002 23:06 schreef crisp het volgende:
ben meer van het shoot-um-up type dan van de RPG games.

ehrm, RTS

Hoe zit het eigenlijk met collision detection bij het onder vuur nemen van een enemy? Is het daar ook voldoende dat je weet dat A op B schiet en dat deze binnen de range zit, dus raak schiet. En igv buiten de range, dat dan een ander target gezocht wordt of gezorgd dat je binnen de range komt?
Of moet je rekening houden met de line-of-fire en objecten die zich in dat pad bevinden op het moment dat daar een straal kogels doorheen vliegt?
Ik dacht de eerste optie.

* Annie blaast de stof van zijn starcraft cd en neemt zich voor het morgen te gaan bekijken, nu eerst

[StarLite]

Op dinsdag 16 juli 2002 00:54 schreef Annie het volgende:

[..]

zoals al eerder gezegd: shame on you
[..]

ehrm, RTS

Hoe zit het eigenlijk met collision detection bij het onder vuur nemen van een enemy? Is het daar ook voldoende dat je weet dat A op B schiet en dat deze binnen de range zit, dus raak schiet. En igv buiten de range, dat dan een ander target gezocht wordt of gezorgd dat je binnen de range komt?
Of moet je rekening houden met de line-of-fire en objecten die zich in dat pad bevinden op het moment dat daar een straal kogels doorheen vliegt?
Ik dacht de eerste optie.

* Annie blaast de stof van zijn starcraft cd en neemt zich voor het morgen te gaan bekijken, nu eerst

tzou wel zo leuk zijn als snelle units trage kogels/missiles/whatever kan ontwijken natuurlijk

[Clay]

missiles zullen altijd auto-homing zijn, lijkt me namelijk nogal moeilijk (en suf) als je met de hand in een rts moet gaan zitten mikken of ontwijken met je units.
Kogels lijkt mij het beste om direct hit te maken. Het enige wat je dan hoeft te doen is een animated pixel "spetter effect" op de target te showen. Dus als een unit op een andere schiet is dat per definitie raak.

niet in het minst ook omwille van detectie, die dan niet nodig is. Alleen voor missile achtige dingen wel dus.

Maareh, na 13 pagina's brainstorming is er denk al redelijk wat footage om wat specs mee in elkaar te draaien (en wat te gaan bouwen). Is't een idee als ik een docje in elkaar mik?

[drm]

In starcraft is het iig zo dat je niets kunt ontwijken. Missiles volgen je gewoon als je 'm peert. En terecht. Maar ik denk dat het een beetje overdreven ingewikkeld wordt als we hierin ook projectiles gaan opnemen als wapens...

Clay:
missiles zullen altijd auto-homing zijn, lijkt me namelijk nogal moeilijk (en suf) als je met de hand in een rts moet gaan zitten mikken of ontwijken met je units.

idd

niet in het minst ook omwille van detectie, die dan niet nodig is. Alleen voor missile achtige dingen wel dus.

hmm...

Maareh, na 13 pagina's brainstorming is er denk al redelijk wat footage om wat specs mee in elkaar te draaien (en wat te gaan bouwen). Is't een idee als ik een docje in elkaar mik?

't is dat ik er geen tijd voor heb, anders had ik het al lang gedaan, maar wat mij betreft: graag

[Verwijderd]

nog even een optimalisatie idee voor collision detection: gefaseerd detecteren. Dit is gebaseerd op het idee dat twee units die heel veel uit elkaar staan elkaar niet permanent in de gaten te hoeven houden, want ze zitten toch niet dicht genoeg bij elkaar in de buurt. Naarmate units dichter bij elkaar komen kan je vaker gaan proben.

Voorbeeldje: stel alle units bewegen met 10 px per sec, als je dan 1 thread om de 5 sec laat proben of twee units dichter dan zeg 60 px bij elkaar zitten (voor alle units), dan kan bij zo'n detectie de kleinste afstand dus 10 px zijn. Op het moment dat units zich binnen die kritische straal zitten, schakel je over naar een thread die vaker probed, afhankelijk van die afstand.

zo hou je dus kritieke gevallen scherp in de gaten en minder kritieke gevallen vreten geen performance.

Ik weet niet of je in javascript de priority van de thread kan instellen, denk het niet eigenlijk, maar dan zou je daar ook nog mee kunnen spelen

[Clay]

Ik denk eigenlijk dat we dat realtime collision tussen units even moeten laten varen, en daar pas actief mee aan de gang moeten gaan als we een soort "speelbaar" geheel hebben waar ueberhaupt verschillende units in voorkomen.

Dan kunnen we ook gaan testen met verschillende soorten collision, wat betreft effectivieteit en perfomance loss. Want eerlijk gezegd vind ik een lekker spelende game belangrijker dan dat 2 untis toevallig over elkaar heen lopen. Al klinkt dat gefaseerd detecteren wel weer lekker

[crisp]

Op dinsdag 16 juli 2002 11:57 schreef mophor het volgende:
nog even een optimalisatie idee voor collision detection: gefaseerd detecteren. Dit is gebaseerd op het idee dat twee units die heel veel uit elkaar staan elkaar niet permanent in de gaten te hoeven houden, want ze zitten toch niet dicht genoeg bij elkaar in de buurt. Naarmate units dichter bij elkaar komen kan je vaker gaan proben.

Voorbeeldje: stel alle units bewegen met 10 px per sec, als je dan 1 thread om de 5 sec laat proben of twee units dichter dan zeg 60 px bij elkaar zitten (voor alle units), dan kan bij zo'n detectie de kleinste afstand dus 10 px zijn. Op het moment dat units zich binnen die kritische straal zitten, schakel je over naar een thread die vaker probed, afhankelijk van die afstand.

zo hou je dus kritieke gevallen scherp in de gaten en minder kritieke gevallen vreten geen performance.

Ik weet niet of je in javascript de priority van de thread kan instellen, denk het niet eigenlijk, maar dan zou je daar ook nog mee kunnen spelen

Dit sluit inderdaad aan op het 'scheidsrechter' principe waar ik mee bezig ben; ik moet behoorlijk mijn wiskunde ophalen om te kijken hoe ik het snelst de afstanden tussen alle objecten kan berekenen
Het idee is dan inderdaad om of:
-alle objecten die dicht bij elkaar staan 'aware' te maken van elkaars aanwezigheid, of
-collision events door de 'scheidsrechter' te laten genereren

De tweede mogelijkheid heb ik al wat mee getest, maar bleek toch vrij zwaar en onnauwkeurig te zijn. Maar dat kan ook zijn omdat ik nog geen snel algorithme heb gevonden om eenvoudig alle afstanden te berekenen aan de hand van de verzameling van x,y coordinaten.

De enige manier om te kunnen 'prioriseren' in JS is denk ik je timeouts van elkaar af te laten wijken.

Maar goed, ik wacht ongeduldig op het docje van Clay!

[Clay]

Docje duurt nog wel ff een paar dagen vandaag ben ik jarig (yay!) morgen, overmorgen, en zaterdag wordt er gefeest dus dat wordt op zijn vroegst zondag denk ik.

[Bosmonster]

Op woensdag 17 juli 2002 09:05 schreef Clay het volgende:
Docje duurt nog wel ff een paar dagen vandaag ben ik jarig (yay!) morgen, overmorgen, en zaterdag wordt er gefeest dus dat wordt op zijn vroegst zondag denk ik.

Gefeliciteerd!

[Verwijderd]

Op woensdag 17 juli 2002 08:33 schreef crisp het volgende:

lalala wiskunde, ieks moeilijk

wellicht kan ik je van dienst zijn met 5 jaar technische natuurkunde achtergrond een een beetje kennis van javascript? zo ja: mailadres = msnadres. (optimalistatie vinnik keitof, je kan bijvoorbeeld ook al gaan zitten denken aan eigen snellere methoden om bijvoorbeeld sinussen uit te rekenen als dat veel voorkomt)

btw clay: gefeliciteerd!

[crisp]

Op woensdag 17 juli 2002 13:48 schreef mophor het volgende:

[..]

wellicht kan ik je van dienst zijn met 5 jaar technische natuurkunde achtergrond een een beetje kennis van javascript? zo ja: mailadres = msnadres. (optimalistatie vinnik keitof, je kan bijvoorbeeld ook al gaan zitten denken aan eigen snellere methoden om bijvoorbeeld sinussen uit te rekenen als dat veel voorkomt)

btw clay: gefeliciteerd!

theorieen zijn bij mij altijd welkom; ik heb zelf 2 jaar universitair wiskunde gehad, dus het meeste begrijp ik hopelijk wel
sinus calculatie heb ik al eens eerder voor AS/400 geschreven, dus dat is ook geen bottleneck. Ik denk echter dat de gewone Math.sin methodes wel snel genoeg zijn.
Enfin, ik heb voor de gein van de smilies maar een spelletje gemaakt; eens kijken wie de hoogste score haalt! (5.111 bytes)

[Pelle]

code:

Shots: 297
Frags: 17 (6%)
Fph: 510
Score: 29

Vogens mij ben je in het voordeel met dit spelletje als je een P100 hebt ofzo

[crisp]

Op donderdag 18 juli 2002 00:39 schreef Pelle het volgende:

code:

Shots: 297
Frags: 17 (6%)
Fph: 510
Score: 29

Vogens mij ben je in het voordeel met dit spelletje als je een P100 hebt ofzo

code:

Shots: 95
Frags: 2 (2%)
Fph: 60
Score: 1

Nee, een AMD XP2000+ is leuk

[LuCarD]

Op donderdag 18 juli 2002 01:01 schreef crisp het volgende:

[..]

code:

Shots: 95
Frags: 2 (2%)
Fph: 60
Score: 1

Nee, een AMD XP2000+ is leuk

Jullie doen het gewoon verkeerd.... )

Shots: 170
Frags: 40 (24%)
Fph: 1200
Score: 282

PIII 1000 )

Bij ging het met de plaatjes alleen af en toe verkeerd. Dan kon hij de plaatjes niet vinden?

En aan het eind kreeg ik een JS error.

edit:

Geen JS error de tweede keer

[crisp]

Op donderdag 18 juli 2002 09:40 schreef LuCarD het volgende:

[..]

Jullie doen het gewoon verkeerd.... )

Shots: 170
Frags: 40 (24%)
Fph: 1200
Score: 282

PIII 1000 )

Bij ging het met de plaatjes alleen af en toe verkeerd. Dan kon hij de plaatjes niet vinden?

En aan het eind kreeg ik een JS error.

edit:

Geen JS error de tweede keer

Waarschijnlijk omdat ik net een nieuwe versie aan het uploaden was (10 bytes kleiner)

[Arnim]

Leuk...

code:

Shots: 86
Frags: 27 (31%)
Fph: 810
Score: 254

Pentium 4 1500

[crisp]

Op donderdag 18 juli 2002 11:12 schreef Arnim het volgende:
Leuk...

code:

Shots: 86
Frags: 27 (31%)
Fph: 810
Score: 254

Pentium 4 1500

Scores enzo liever in dit topic posten, anders gaan we veel te ver offtopic hier...

[Bosmonster]

Toch ook maar ff gedaan dan..

Shots: 72
Frags: 27 (38%)
Fph: 810
Score: 304

Gewoon mikken op de langzame

[edit]
oops.. zie nu je reactie pas

[daaf258]

Grr kan niet (mag niet ) op dat forum komen.

psst.
Shots: 175
Frags: 83 (47%)
Fph: 2490
Score: 1181

op amd 1700+

[Verwijderd]

Hmm, hij doet het wel op 'n Mac (G4 700), maar de events van IE5.2 zuigen. Mozilla op de mac wil ook al niet echt opschieten. Ik zal 'm volgende week 's op w2k bekijken.

Je kunt hem trouwens wel inzenden voor de 5k wedstrijd

[drm]

<sup>Shots: 120
Frags: 35 (29%)
Fph: 1050
Score: 306

hmm... * drm wil geen rsi, en doet dat spelletje nooooooiit meer...</sup>


Laten we voor de grap weer even ontopic gaan

[crisp]

Op donderdag 18 juli 2002 21:41 schreef Doekman het volgende:
Hmm, hij doet het wel op 'n Mac (G4 700), maar de events van IE5.2 zuigen. Mozilla op de mac wil ook al niet echt opschieten. Ik zal 'm volgende week 's op w2k bekijken.

Je kunt hem trouwens wel inzenden voor de 5k wedstrijd

Moz 1.1 onder win2k doet het toch best aardig, lagere Moz versies hebben sowieso veel moeite met layer-verplaatsingen.
Het was inderdaad mijn doel om onder de 5k te komen; helaas moet ik nog een jaartje wachten voor de volgende wedstrijd. Misschien kan ik de popup-puzzle ook nog wel gebruiken, maar dan dat je zelf een plaatje van je harde schijf kan kiezen als puzzel

Om toch niet helemaal off-topic te gaan hier, nog een interessant feitje dat ik ontdekt hebt:
Onder IE geven de clientX en clientY positie van een event in een browservenster (dus geen AD) altijd 2 pixels te veel weer!

[Mithrandir]

Ik heb een offtopic vraagje:

Hoe vinden jullie al die pre-defined variables? Ik kan _nergens_ een lijstje vinden van die dingen of een function-overview. Ik heb gekeken op MSDN, de site van Netscape, w3 en google. Ik kan het niet vinden.

Willen jullie me even op weg helpen?

[Bosmonster]

Op zondag 21 juli 2002 11:31 schreef Mithrandir het volgende:
Ik heb een offtopic vraagje:

Hoe vinden jullie al die pre-defined variables? Ik kan _nergens_ een lijstje vinden van die dingen of een function-overview. Ik heb gekeken op MSDN, de site van Netscape, w3 en google. Ik kan het niet vinden.

Willen jullie me even op weg helpen?

Beter kijken Je moet het niet zien als een verzameling voorgedefinieerde zut, maar je moet het zien als een Object Model, met methodes en eigenschappen. Info hierover is zowel op MSDN als op W3C te vinden.

Maar wat heeft dit in godsnaam met Snowstorm te maken

[Mithrandir]

Op zondag 21 juli 2002 11:39 schreef Bosmonster het volgende:

[..]



Beter kijken Je moet het niet zien als een verzameling voorgedefinieerde zut, maar je moet het zien als een Object Model, met methodes en eigenschappen. Info hierover is zowel op MSDN als op W3C te vinden.

Maar wat heeft dit in godsnaam met Snowstorm te maken

Nog een topic erover maken is wat ehm... verspilling. En aangezien dit DHTML is, waarvan de D behoorlijk door JavaScript wordt gemaakt...

/edit
Juist, volgens mij heb ik het gevonden... Leuk als je naar JavaScript zoekt en je moet DOM hebben
Nouja, hier is de link iig. Misschien iets voor een -uitgebreidere- faq?
[url="http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/def-index.html"]http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/def-index.html[/url]

/edit2
Waarom heet JavaScript hierzo ECMAScript? Zo kan ik het ook, iedere keer 't anders noemen

[Bosmonster]

Op zondag 21 juli 2002 11:42 schreef Mithrandir het volgende:

[..]

Nog een topic erover maken is wat ehm... verspilling. En aangezien dit DHTML is, waarvan de D behoorlijk door JavaScript wordt gemaakt...

/edit
Juist, volgens mij heb ik het gevonden... Leuk als je naar JavaScript zoekt en je moet DOM hebben
Nouja, hier is de link iig. Misschien iets voor een -uitgebreidere- faq?
[url="http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/def-index.html"]http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/def-index.html[/url]

/edit2
Waarom heet JavaScript hierzo ECMAScript? Zo kan ik het ook, iedere keer 't anders noemen

ECMAScript is de scriptstandaard die aan JavaScript ten grondslag ligt. Ook bijvoorbeeld Flash Actionscript is hierop gebaseerd. ECMAScript is gebaseerd op JavaScript van Netscape en JavaScript is vervolgens doorontwikkeld op basis van de ECMAScript standaard.

ECMAScript is niet als zodanig te gebruiken in je browser (hoewel sommigen het wel geprobeerd hebben ). We noemen in de browser ECMAscript gewoon JavaScript (Of IE's JScript), omdat anders alle namen veranderd moesten worden intern en in alle websites van mensen. W3 ziet echter in de toekomst toch graag dat alle browsers volledig ECMAscript compliant worden, ipv de verschillende interpretaties die nu gebruikt worden.

Wat DOM betreft. Dat is het model gebaseerd op XML om HTML elementen te kunnen identificeren in een pagina. De (visuele) eigenschappen van deze elementen zijn gedefinieerd middels CSS. Denk aan achtergrondkleur, lettertypes, borders, margins, etc. Zoek je deze dan moet je dus zoeken op CSS. Zoek je een functie om een element te vinden dan zoek je op DOM/XML.

[Mithrandir]

Op zondag 21 juli 2002 12:26 schreef Bosmonster het volgende:

[..]

ECMAScript is de scriptstandaard die aan JavaScript ten grondslag ligt. Ook bijvoorbeeld Flash Actionscript is hierop gebaseerd. ECMAScript is gebaseerd op JavaScript van Netscape en JavaScript is vervolgens doorontwikkeld op basis van de ECMAScript standaard.

ECMAScript is niet als zodanig te gebruiken in je browser (hoewel sommigen het wel geprobeerd hebben ). We noemen in de browser ECMAscript gewoon JavaScript (Of IE's JScript), omdat anders alle namen veranderd moesten worden intern en in alle websites van mensen. W3 ziet echter in de toekomst toch graag dat alle browsers volledig ECMAscript compliant worden, ipv de verschillende interpretaties die nu gebruikt worden.

Wat DOM betreft. Dat is het model gebaseerd op XML om HTML elementen te kunnen identificeren in een pagina. De (visuele) eigenschappen van deze elementen zijn gedefinieerd middels CSS. Denk aan achtergrondkleur, lettertypes, borders, margins, etc. Zoek je deze dan moet je dus zoeken op CSS. Zoek je een functie om een element te vinden dan zoek je op DOM/XML.

Dankjewel voor je stuk text
Maar welke DOM moet ik gebruiken? Level 1, 2 of 3? Is 3 al uitontwikkeld, en welke versie (XPath, HTML, Core Specification, etc)

[Bosmonster]

Op zondag 21 juli 2002 12:36 schreef Mithrandir het volgende:

[..]

Dankjewel voor je stuk text
Maar welke DOM moet ik gebruiken? Level 1, 2 of 3? Is 3 al uitontwikkeld, en welke versie (XPath, HTML, Core Specification, etc)

Hangt af van je browser.. over het algemeen lopen ze behoorlijk achter, wat ook wel logisch is. Dit haal ik simpelweg van de Microsoft site:

Standards support. As part of rounding off support for the CSS and DOM level 1 standards, Internet Explorer 6 incorporates support for the optgroup element and introduces DOM methods such as getAttributeNode, setAttributeNode, createAttribute, and others. For more information, see the optgroup documentation and DHTML methods.

Over het algemeen kun je uitgaan van DOM en CSS lvl 1, maar echt nauwkeurig is dit niet.. Ie had lvl 1 ondersteuning nog niet af, maar wel sommige features van lvl 2 geimplementeerd. En nog custom features natuurlijk Kijk ook maar naar Mozilla.org wat betreft Mozilla:

Better HTML support (CSS 1 and partial CSS 2, DOM 1 and partial DOM 2)

En uiteraard moet je de HTML DOM hebben, al is de W3.org site niet altijd even nuttig als naslag voor ontwikkeling.. omdat je nooit zeker weet of je browser het ondersteunt of niet.. (tja was is 'partial support')

[Mithrandir]

Op zondag 21 juli 2002 12:50 schreef Bosmonster het volgende:

[..]

Hangt af van je browser.. over het algemeen lopen ze behoorlijk achter, wat ook wel logisch is. Dit haal ik simpelweg van de Microsoft site:
[..]

Over het algemeen kun je uitgaan van DOM en CSS lvl 1, maar echt nauwkeurig is dit niet.. Ie had lvl 1 ondersteuning nog niet af, maar wel sommige features van lvl 2 geimplementeerd. En nog custom features natuurlijk Kijk ook maar naar Mozilla.org wat betreft Mozilla:
[..]

En uiteraard moet je de HTML DOM hebben, al is de W3.org site niet altijd even nuttig als naslag voor ontwikkeling.. omdat je nooit zeker weet of je browser het ondersteunt of niet.. (tja was is 'partial support')

Ok. Dankjewel. Ik ga nu uitzoeken wat welke browsers ondersteunen. Ken je de HTML-tag-list? Misschien is zoiets voor JavaScript wel handig, bedenk ik me... Misschien leuk projectje? Ik zie wel ff. Dankjewel voor je info!

[Verwijderd]

Op zondag 21 juli 2002 11:31 schreef Mithrandir het volgende:
Ik heb een offtopic vraagje:

Hoe vinden jullie al die pre-defined variables? Ik kan _nergens_ een lijstje vinden van die dingen of een function-overview. Ik heb gekeken op MSDN, de site van Netscape, w3 en google. Ik kan het niet vinden.

Willen jullie me even op weg helpen?

Voor een overzicht van alles betreffende DHTML voor MSIE:
[url="http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/dhtml_reference_entry.asp"]Klik hier.[/url]

En nu weer ontopic?

[Mithrandir]

Op zondag 21 juli 2002 14:55 schreef Triyazo het volgende:

[..]

Voor een overzicht van alles betreffende DHTML voor MSIE:
[url="http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/dhtml_reference_entry.asp"]Klik hier.[/url]

En nu weer ontopic?

<offtopic id = "nog meer offtopic">
Dat jullie iets kunnen vinden op die site van MS... IK wordt er helemaal gek van. Nouja. Kan aan mij liggen
</offtopic>

[Verwijderd]

Op zondag 21 juli 2002 15:08 schreef Mithrandir het volgende:
Dat jullie iets kunnen vinden op die site van MS... IK wordt er helemaal gek van. Nouja. Kan aan mij liggen

Misschien moet je jezelf eens [url="http://www.oreilly.com/catalog/jscript4/"]dit boek[/url] kado doen. Dat houdt je voorlopig van de straat.

[Pelle]

* Pelle doet ook het vriendelijke verzoek het ontopic te houden

Wil je meer weten over DHTML, open dan gerust een nieuw topic

[drm]

ONtopic woei

_{hersenspinsel-mode aan}

Ik heb van het weekend nog even na zitten denken over wat mophor zei in zijn post over het optimaliseren van collision:
_{[quote]
mophor:
gefaseerd detecteren. Dit is gebaseerd op het idee dat twee units die heel veel uit elkaar staan elkaar niet permanent in de gaten te hoeven houden, want ze zitten toch niet dicht genoeg bij elkaar in de buurt. Naarmate units dichter bij elkaar komen kan je vaker gaan proben.
[/quote]}



Hij geeft echter als voorbeeld 2 statussen: 1 waarbij er maar om de 5 seconden geprobed hoeft te worden, en 1 waarbij er constant geprobed moet worden.

Mijns inziens hoeft die 5 geen constante te zijn. Als ik iets raars zeg hoor ik het wel, maar dit was mijn idee:

Unit A en Unit B staan afstand pixels (of stapjes) bij elkaar vandaan. A kan met snelheid y stapjes per seconde en B kan met snelheid z stapjes per seconde.

Wanneer kunnen deze units gaan colliden?

• snelheid[sub]A[/sub] = y[sup]p[/sup]/[sub]s[/sub] snelheid[sub]B[/sub] = z[sup]p[/sup]/[sub]s[/sub] afstand = x time is de [i]next possible collision[/i]

oftewel, collision treedt op wanneer

• x = (snelheid[sub]A[/sub] * time) + (snelheid[sub]B[/sub] * time)

oftewel

• x = (snelheid[sub]A[/sub] + snelheid[sub]B[/sub]) * time

wanneer wij deze vergelijking op willen lossen in de vorm time = krijgen wij:

• time = x / (snelheid[sub]A[/sub] + snelheid[sub]B[/sub])

Wanneer wij nadat time verstreken is inderdaad kijken of er collision optreedt, en dit blijkt niet zo te zijn, hebben we een nieuwe x (afstand tussen A en B) en kan de tijd tot volgende collision opnieuw berekend worden. Anders is heb je collision en doe je wat er gedaan moet worden.

Je zult wel wat probleempjes tegenkomen met dit verhaal, maar volgens mij klopt 't aardig... 't Probleem is natuurlijk dat dit verhaal helemaal opgaat wanneer A en B een ééndimensionaal object voorstellen (een punt dus ).

Hoe je 't precies af moet vangen wanneer ze 2 dimensionaal zijn weet ik niet (heb ik nog niet over nagedacht), maar 't principe moet 'tzelfde kunnen zijn.

Als 't onzin is hoor ik 't wel

_edit:typo

[Pelle]

* Pelle ^^

[Skef]

Op maandag 22 juli 2002 10:21 schreef drm het volgende:
Unit A en Unit B staan afstand pixels (of stapjes) bij elkaar vandaan. A kan met snelheid y stapjes per seconde en B kan met snelheid z stapjes per seconde.

Wanneer kunnen deze units gaan colliden?

• snelheid[sub]A[/sub] = y[sup]p[/sup]/[sub]s[/sub] snelheid[sub]B[/sub] = z[sup]p[/sup]/[sub]s[/sub] afstand = x time is de [i]next possible collision[/i]

oftewel, collision treedt op wanneer

• x = (snelheid[sub]A[/sub] * time) + (snelheid[sub]B[/sub] * time)

oftewel

• x = (snelheid[sub]A[/sub] + snelheid[sub]B[/sub]) * time

wanneer wij deze vergelijking op willen lossen in de vorm time = krijgen wij:

• time = x / (snelheid[sub]A[/sub] + snelheid[sub]B[/sub])

Wanneer wij nadat time verstreken is inderdaad kijken of er collision optreedt, en dit blijkt niet zo te zijn, hebben we een nieuwe x (afstand tussen A en B) en kan de tijd tot volgende collision opnieuw berekend worden. Anders is heb je collision en doe je wat er gedaan moet worden.

Je zult wel wat probleempjes tegenkomen met dit verhaal, maar volgens mij klopt 't aardig... 't Probleem is natuurlijk dat dit verhaal helemaal opgaat wanneer A en B een ééndimensionaal object voorstellen (een punt dus ).

Hoe je 't precies af moet vangen wanneer ze 2 dimensionaal zijn weet ik niet (heb ik nog niet over nagedacht), maar 't principe moet 'tzelfde kunnen zijn.

Dit is absoluut geen onzin, het moet echter wel verfijnd worden.

Allereerst: Ik zou niet uitgaan van de "next-possible-collision", maar ik zou een tijdstip hiervoor berekenen, omdat je anders op het moment dat er collision optreedt berekend dat er een collision plaatsvindt...

Dit zou je procentueel kunnen doen (bijv. op 90% van de tijd een nieuwe berekening), of aan de hand van het mogelijke pad wat de beide units afleggen om een collision op te laten treden.

Wat betreft de 2-dimensionale-units: Een unit heeft dan toch 4 hoek-coordinaten, waarvan er van beide units 2 het dichtst bij elkaar liggen? Aan de hand van die 2 coordinaten ga je rekenen (lijkt mij)... Mocht een unit tijdens zijn "collision-tocht" draaien/van richting veranderen, dan bekijk je opnieuw welke 2 coordinaten het dichtst bij elkaar liggen...

En nu dit verhaaltje nog uitdenken voor meerdere units, en groepen units....... Wie denkt er mee?

[drm]

^*SCHOP!*

Clay, heb je al wat bereikt met je docje?

[Verwijderd]

[b]Op maandag 22 juli 2002 10:21 schreef drm een prachtig verhaal over collision detection

mijn idee was idd een probesnelheid afhankelijk van de afstand tussen de twee objecten, dat kan in stapjes (om de 5 sec en (semi)continu) of als een lineaire functie van de afstand (wat drm zegt en in principe neerkomt op onderverdelen in oneindig veel stapjes)

ik ga even proberen (al denkend) het verhaal in een duidelijke vorm te gieten

elke unit (A,B,...) heeft 4 coordinaten in de snelheidsruimte, een xpositie (x) een ypositie een xsnelheid (u) en een ysnelheid (v) bovendien nog een botsingsstraal (r), x en y vormen de plaatsvector X en u en v vormen de snelheidsvector U. je kan ook nog een veiligheidsgebied definieren waarbinnen minstens een keer gedetecteerd moet worden (zeg maar een soort virtuele straal van de unit, die natuurlijk groter is dan de eigenlijke straal r) (R)

de maximale snelheid waarmee units A en B elkaar kunnen naderen is |U_A| + |U_B|
die we s noemen

de echte snelheid tov elkaar wordt simpel gegeven door de vectorsom.

voor de afstand geldt het vectorverschil X_A - X_B en die noemen we q

van die afstand halen we de tweemaal de veiligheidsstraal af (q-2R) als we absoluut veilig willen zijn moet dus het probe interval gelijk zijn aan (q-2R) / s

(bouw hier wel even een check in of de units niet toevallig stil staan, dan krijg e een deling door 0, maar dat hadden jullie vast al wel door)

het is al laat, dus check mijn verhaal effe aub

[crisp]

Op donderdag 25 juli 2002 22:59 lulde mophor nog eens door over collision detection

Allemaal leuk en aardig, maar ondertussen heb ik eens wat testjes gedaan met een zogenaamde 'referee-thread'; oftewel een aparte thread die de afstanden van alle objecten ten opzichte van elkaar in de gaten houd, en collision events triggered (hetzij door zelf het event aan te roepen, hetzij door een property van de objecten te zetten waardoor zij zelf de collision afhandelen).

Ik heb hier tot nog toe geen performancewinst uit kunnen halen...

De volgende problemen spelen namelijk mee:

-Een referee moet in de eerste plaats alle afstanden, richtingen en snelheden bepalen van alle objecten om te bepalen wanneer eventueel een collision optreedt. Bij bijvoorbeeld 10 objecten levert dit 10*9*8*7*6*5*4*3*2*1 resultaten op die al dan niet na een bepaalde interval opnieuw gechecked dienen te worden.
-Echter: treed er eenmaal een collision op, dan moeten er weer 16 berekeningen plaatsvinden omdat object 1 van richting & snelheid veranderd (8 berekeningen) en omdat object 2 van richting & snelheid veranderd (8 berekeningen).
-Als een object alleen van richting veranderd (botsen tegen een muur bijvoorbeeld) dan moeten er 9 berekeningen gedaan worden.

De situatie kan dus na 1 collision of na 1 verandering van richting dusdanig veranderen dat je weer timeouts moet gaan cancellen en herberekenen; het geheel wordt daardoor eerder zwaarder en trager dan dat het voordeel oplevert. Zeker met snel bewegende objecten en veel collisions....

[Verwijderd]

ik had nog een verder gevorderd idee. als je op een bepaald moment van alle units nagaat of ze met elkaar kunnen colliden en zo ja waar en wanneer, dan kun je voor elke unit deze ruimtetijdcoordinaten opslaan in een array die die unit meedraagt (als ze niet eens kunne colliden dan sla je null, NIL of -1 op ofzo). dit zijn waarschijnlijk een stel zware berekeningen. heeft echter als voordeel dat je dan wel meteen weet wat de "hete" units zijn. vervolgens kan je (eventueel gefaseerd weer) bijhouden of een unit in z'n eigen gevaarlijke gebieden komt (cirkels met de veiligheidsstraal R rond de punten in z'n array) dit zullen slechts enkele simpele berekeningen zijn.

op het moment dat er een collision plaatsvind en de plaatssnelheidshector dus veranderd, moet voor dat object de collisionplaats en tijd voor alle anderen opnieuw berekend worden en weggeschreven worden in z'n eigen array (en ook gepushed in de corresponderende arrayplaatsen van andere units) dat zijn dus 9 berekeningen in het geval van 10 units, die alleen maar plaats vinden als er een collision plaatsvind.

mischien kan iemand met wat meer wiskundekennis hier even wat formules voor neerkwakken, als je namelijk uitgaat van die veiligheidsstraal, beschrift elke unit een gescewde cylinder in de ruimtetijd. als die cylinders elkaar niet raken krijg je dus geen collision, als ze elkaar ergens snijden dan is het punt met de kleinste tijd de ruimtetijdcoordinaat van de botsing. (als dat pas over 5 minuten ofzo is hoef je daar voorlopig niet naar te kijken)

----

edit: je doet dit natuurlijk alleen voor de onscreen units, ik neem aan dat alle units wel een vlaggetje meekrijgen of ze on - of offscreen zijn. Voor offscreen dingen kan je een simpeler algoritme bedenken waar Clay het hieronder over heeft.

Op zich vinnik trouwens dat Clay wel gelijk heeft, hoewel ik denk dat er heel wat te optimaliseren is, en dan misschien in zoverre dat het toepasbaar is. Het zou natuurlijk wel errug kloek zijn als je een goede collision detection zou realiseren, maar misschien kunnen we er inderdaad voorlopig beter even over ophouden en gaan richten op de broodnodige features.

misschien kunnen we even een lijstje maken van dingen waar even over nagedacht moet worden (of was dat er al?)
Ik heb al een simpele objectstructuur voorbi zien komen en hieronder zegt Clay dattie een docje in elkaar aan het flansen is, waar ik al naar uitkijk

[Clay]

Collision is natuurlijk heel tof, maar ik blijf het ondergeschikt vinden aan andere game elementen die ook relatief rekenintensief kunnen worden. realtime collision zou inderdaad heel vet zijn, maar die optimalisaties moeten ook werkelijk minder berekeningen tot gevolg hebben, en ik zie in veel ideeen eigenlijk alleen meer rekenproblemen.
Een check of de afstand tussen 2 units binnen de beide stralen ligt is zo gebeurd. Er hoeft niet gebounced te worden tussen die units, dus die berekeningen zijn er niet, en de effectiefste optimiser is een check op snelheid die de collision check abort als beide units stilstaan. De beperking zit um in het moven van tientallen layers tegelijk.

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.

Ben het hier heel erg mee eens, met dan een stuk of wat units per tile. Lekker boeien als ze elkaar dan soms wat overlappen Maar ik ga nu ff wat in een docje zetten denk ik.

[Clay]

[url="http://www.xs4all.nl/~peterned/got/snowstorm/overzichtje.html"]Overzicht[/url] (zo'n beetje dan) van wat er tot nu toe ongeveer ter sprake is gekomen.

[edit]
oerdom ja

[crisp]

Op vrijdag 26 juli 2002 18:03 schreef Clay het volgende:
[url="http://D:\Web building\Projects\dhtml snowstorm\overzichtje.html"]Overzicht[/url] (zo'n beetje dan) van wat er tot nu toe ongeveer ter sprake is gekomen.

Waarom mag ik niet op jouw harde schijf komen?

[edit]
la ma, al gefix0red zie ik

[Woudloper]

Clay schreef op 26 juli 2002 @ 18:03:
[url="http://www.xs4all.nl/~peterned/got/snowstorm/overzichtje.html"]Overzicht[/url] (zo'n beetje dan) van wat er tot nu toe ongeveer ter sprake is gekomen.

Ziet er mooi uit!!

Zo even na de vakantie het één en ander doorgelezen en weet dan meteen weer waar we staan...

_{PS: Eigenlijk is dit stiekempies een kleine *kick*}

[Verwijderd]

Ik heb even een inventarisatie gemaakt van alle links die voorbij zijn gekomen (maar ik ben nog maar halverwege).

_{PS: Woudloper, je was me voor}

[LuCarD]

Oops waar trap ik nu weer tegen aan?

[Verwijderd]

trapje omhoog!!!!

[Clay]

Ik denk dat we ff moeten wachten met echt bruute dingen tot de vakanties weer over zijn enzo ik zit vanaf komende zaterdag ook 2 weken ergens anders, dus voorlopig kan ik er ook ff niet al te veel tijd insteken.

[Woudloper]

Clay schreef op 13 augustus 2002 @ 12:08:
Ik denk dat we ff moeten wachten met echt bruute dingen tot de vakanties weer over zijn enzo ik zit vanaf komende zaterdag ook 2 weken ergens anders, dus voorlopig kan ik er ook ff niet al te veel tijd insteken.

Lijkt mij ook verstandig Ik ben wel net terug, maar wacht nog even op wat zaken. Ik dacht dat jij (Clay) nog wat zou schrijven of niet Wellicht zou je zo vlak voor je vakantie nog een opzet kunnen geven en wellicht wat (test) acties uitzetten zodat we wat kunnen doen

[David]

drm schreef op 12 juni 2002 @ 23:50:
Clay kwam met het idee om een StarCraft-achtige DHTML-game te maken. Hij acht dit haalbaar, en met hem een aantal anderen. Hoe lang het gaat duren boeit (mij) niet. Als 't maar wat wordt

Cool! Ik heb er een tijd terug met een vriend van me aan gedacht om een soort van Warcraft2 in DHTML te maken. Nooit wat geworden, maar toch.

Als je dus nog iemand voor dit project zoekt: here I am!

Mijn kwaliteiten:
-Kennis van DHTML, XHTML, XML (duh!), PHP, MySQL, Java <- niet echt goede progger alleen
-Verfent Starcraft/War3/War2-speler
-Creatief (met muziek, verhaaltjes maken en plaatjes maken)
-Zin om mee te doen, te coden, te tekenen/muziekmaken/opnemen en te betatesten
-Vast nog wel wat kwaliteiten waarvan ik nu denk dat ze niet relevant zijn, maar die misschien wel relevant zijn.

[drm]

Brainstorm lekker mee zou ik zeggen...

't staat nu enkel op een laag pitje omdat 't meerendeel op vakantie is, of het te druk heeft, maar dat geeft niks. Als je 't topic hebt gelezen, kun je misschien hier en daar ook nog wat comments geven

[David]

Ik was al bezig de boel door te spitten, maar op pagina 5 kon ik het echt niet meer houden ! (zit nu ergens op pag. 10)

Misschien ook wel handig om regels voor de (X)HTML en CSS op te stellen. Veel mensen schrijven HTML-tags nog in upper case, maar i.v.m. compatibility met XHTML en XML kunnen we het beste gewoon de recommendation van W3C voor XHTML 1.0 aanhouden.

Waarom staat multiplayer buiten kijf? We kunnen toch gewoon PHP gebruiken? Geen Flash of wat dan ook voor nodig. Probleem is alleen dat je superveel moet verzenden naar de server, maar daar komt wel iets voor (hoop ik).

Is het misschien iets om één site te maken voor Snowstorm waarop alle vorderingen (oa. van http://www.xs4all.nl/~pet...nowstorm/overzichtje.html), ideeën en voorbeelden geplaatst kunnen worden? Ik wil deze evt. wel maken/hosten (er zullen vast wel meer webdesigners staan te springen om dit te doen ). Dat is wat overzichtelijker dan nu (ik ben nieuwkomer, heb 13 pagina's door moeten spitten om ook maar een samenvatting te vinden en weet nog steeds niet hoe ver jullie nou 'echt' zijn)

[drm]

DiMension:
Ik was al bezig de boel door te spitten, maar op pagina 5 kon ik het echt niet meer houden ! (zit nu ergens op pag. 10)

Misschien ook wel handig om regels voor de (X)HTML en CSS op te stellen. Veel mensen schrijven HTML-tags nog in upper case, maar i.v.m. compatibility met XHTML en XML kunnen we het beste gewoon de recommendation van W3C voor XHTML 1.0 aanhouden.

Doorgaans zullen we niet veel HTML en CSS nodig hebben, denk ik. In eerste instantie zal het meest in JS gemaakt moeten worden, een de deelproblemen wat dat betreft opgelost....

Waarom staat multiplayer buiten kijf? We kunnen toch gewoon PHP gebruiken? Geen Flash of wat dan ook voor nodig.

RTFT!! DHTML Project. 't Blijft dus voorlopig ook gewoon DHTML, en niet meer.

Is het misschien iets om één site te maken voor Snowstorm waarop alle vorderingen (oa. van http://www.xs4all.nl/~pet...nowstorm/overzichtje.html), ideeën en voorbeelden geplaatst kunnen worden? Ik wil deze evt. wel maken/hosten (er zullen vast wel meer webdesigners staan te springen om dit te doen ). Dat is wat overzichtelijker dan nu (ik ben nieuwkomer, heb 13 pagina's door moeten spitten om ook maar een samenvatting te vinden en weet nog steeds niet hoe ver jullie nou 'echt' zijn)

D'r is in principe ook nog niets af. We zijn nog steeds min of meer in de brainstorm-fase. Maar ik heb zelf nog geen tijd gehad dat k*tsite-je van mij af te maken, maar zodra ik wel tijd heb, hou ik het daar bij. Maar ik weerhoud jou (en niemand) er van om even een samenvatting of een andere site te fix0ren.

edit:

offtopic:
Hm, ik zie ook dat mijn 1337 icon in dit topic 't niet doet, sinds react... ff wat aan doen, dan maar

[ Voor 0% gewijzigd door drm op 21-08-2002 16:07 . Reden: done ]

[Annie]

brainstorm? wordt het niet eens tijd voor een brainnicesummerevening
m.a.w. ik wil natuurlijk wel ooit nog iets kunnen beta testen natuurlijk, dus: ggg (GoGoGo)

[David]

Speel hier maar mee totdat je een bug ontdekt

Da's alles wat we tnt hebben geloof ik

[David]

Toch aan het doodbloeden dit project?

Ik heb nog wel een paar vraagjes:
-Is het in js/ECMA wel mogelijk verschillende units te selecteren?
-Welke versie javascript/ECMA gaan we vanuit?
-Wie doet wat? (een soort van losse taakverdeling is wel handig in zown project)
-Hoe bouwen we de basis van een level op? Is dat 1 pic, of meerdere pics gespecificeerd in een XML-bestand ofzo?

[Woudloper]

DiMension schreef op 26 augustus 2002 @ 15:35:
Toch aan het doodbloeden dit project?

Nee hoor Er zijn nog verschillende mensen op vakantie en daarnaast hebben de werkende het onder ons waarschijnlijk druk! Ik ook , maar dat zal de pret niet drukken. Denk dat we ook nog even moeten wachten op Clay aangezien hij nog het één en ander zou produceren zodat we met zijn Beehive2 (speciaal voor Snowstorm) aan de gang kunnen gaan...

• Is het in js/ECMA wel mogelijk verschillende units te selecteren?

Naar mijn idee is dat mogelijk

• Welke versie javascript/ECMA gaan we vanuit?

Gezien je toch al het hele topic hebt gelezen weet je dat we in eerste instantie hebben gekozen om alleen voor IE te werken gezien dit de ontwikkeling vereenvoudigd. Weet even niet welke versie dat is, maar wel één van de meest recentse (1.3 )

• Wie doet wat? (een soort van losse taakverdeling is wel handig in zown project)

Er is ooit een begin verdeling gemaakt, maar wie doet wat is niet gespecificieerd. Je roept maar wat jou kwaliteiten zijn en dan wordt dat ingepast in het project. Als jij bijvoorbeeld x. wilt maken dan roep je maar. Het wachten is nog op de engine en zoals eerder gezegd de maker (clay) is op vakantie.

• Hoe bouwen we de basis van een level op? Is dat 1 pic, of meerdere pics gespecificeerd in een XML-bestand ofzo?

Meerdere pics lijkt mij, dit omdat je dan eenvoudiger verschillende levels zou kunnen opbouwen. Maar dat staat nog redelijk open. Mocht jij nog suggesties hebben welke kant jij op dacht dan moet je dat maar zeggen. In een oudere posting heeft Clay ooit een voorbeeld laten zien hoe een veld opgebouwd kon worden met behulp van meerdere pics...

[drm]

* drm hoopt v.a. morgen weer internet thuis te hebben yay
dat scheelt alvast weer een hele hoop...

Was afgelopen paar dagen op LowLands, en zo heel erg nat was 't niet, hoor Veel modder, dat wel...

Maar goed, om even ontopic te blijven, we wachten idd nog een beetje op Clay met de specificaties van 't project, dan wordt de werkverdeling wat beter. Als ik doordeweeks weer wat meer tijd heb, kan ik ook aan de site verder, die nu nog (steeds) helemaal nergens over gaat, maar dat komt dan wel

offtopic:
Woudloper: Please comment your code properly

[Clay]

Summerbreeze in Ambstgmuend (zuid duitsland) mocht er ook wezen 3 dagen geen modder gezien, wel heel veel zon en Nightwish! Woei! Tarja!

Maargoed, de komende paar dagen heb ik het lekker rustig, dus ik zal ff kijken of ik wat orde op zake kan stellen zodat we binnenkort ook een keer echt wat kunnen gaan bouwen. Beehive 2 is daarnaast ook eigenlijk zga af basis-classmodel & code-skelet zou in principe al wel mogelijk moeten zijn.

[David]

Kort vraagje: commenten we in het Nederlands of in het Engels? Zelfde geldt voor functie/variabelennamen.

[Woudloper]

DiMension schreef op 28 augustus 2002 @ 21:07:
Kort vraagje: commenten we in het Nederlands of in het Engels? Zelfde geldt voor functie/variabelennamen.

Persoonlijk zal ik zeggen, we schrijven ons commentaar (en de functiebenamingen) in het Engels. Dit zorgt er ook voor dat het project voor een breder publiek te zien is (Qua source e.d. bedoel ik dan).

Wel kan het gewoon zo zijn dat Clay zijn documentatie (voor Beehive2) gewoon in het Nederlands schrijft (We zijn immers allemaal de NL taal machtig).

[drm]

Wat mij betreft allemaal lekker Engels. Ik (en velen met mij) coderen in 't Engels, omdat JavaScript (en vele andere talen) tenslotte ook een soort van "engels" is (if,else,while,for,...)

[David]

Ik ben ook voor Engels. De meeste computer/progtermen zijn namelijk in het engels.

[Verwijderd]

Hoe staat het er eigenlijk mee? (het project dus)

[Clay]

Wat mij betreft kunnen we het weer oppikken, vakantie moet toch wel zo'n beetje voorbij zijn voor iedereen of niet?

[T. van Beek]

yup, off you go!

[crisp]

Clay schreef op 08 september 2002 @ 12:47:
Wat mij betreft kunnen we het weer oppikken, vakantie moet toch wel zo'n beetje voorbij zijn voor iedereen of niet?

Nee hoor, over een week heb ik pas vakantie
Maar liefst 1 week om lekker thuis achter mijn computer te kunnen kruipen

[drm]

offtopic:
crisp: vergeet niet om bier in te slaan, he

Clay, zou je een update kunnen doen over wat je al aan "documentatie" heb geschreven.

[killercow]

hey dudes geweldig plan hier, nadat de got 3d engine niet geslaagd was ben ik in m'n eentje gaan programmeren aan een web-based isometric engine zoals in bijvoorbeeld transport/rollercoaster tycoon gebruikt wordt.

de code in dit project houd ik het liefst closed maar dat wil natuurlijk niet zeggen dat ik niet mee wil helpen een jullie project.

ik heb op het moment:
een 3d map, met verschillende hoogte levels
een map generator (gebruikt photoshop clouds filter als height map)
een client-server protocol om units te bewegen en om multiplayer mogenlijk te maken
een mysql databse om de boel op te slaan.
een tile generator die verschillende tiles aanmaakt (deze moet nog kleurverschillen (schaduw/zonkant) laten zien)

hiermee kan ik vanaf een photoshop plaatje met een clouds filter erin een speelmap aanmaken die uit 2500 tiles bestaat en zo ongeveer 10 hoogtes bevat, hierop kunnen dan units bewogen worden.

laat het me even weten als jullie meer willen oren/zien
zo ja zoek even op isometric of op mijn naam op got en je zult vast iets vinden.

[Clay]

whoa, vet heb je ergens een versie draaien om te spieken? En waarin heb je dat gebouwd?

[killercow]

uhm mysql+php om de map op te bouwen en de coordinaten uit te vinden, javascript als front end

multiplayer met een ghost-frame die gevuld wordt door php en mysql die da dhtml functies aanroept.

ik zal een kijken ofhet allemaal werkt aangezien ik gister verhuist ben naar m'n eigen server

ik heb zowiezo plaatjes voor je.
kijk hier maar even:

http://www.pc-gamers.com/....php?op=newindex&catid=11

[HawVer]

DiMension schreef op 22 augustus 2002 @ 00:09:
Speel hier maar mee totdat je een bug ontdekt

Da's alles wat we tnt hebben geloof ik

Het is niet echt een bug. Maar als je je muis inhoud en vanaf het midden naar beneden beweegt sleep je één van de plaatjes eruit. Die verschijnd dan als enigste in het scherm

[HawVer]

Heej daniel_hoenderdos. Klopt het dat jij door je webicon een cookie laat zetten van een één of andere reclame site? En wel deze http://www.qksrv.net/ site?

Edit: laat maar ik heb hem al gevonden!

[Clay]

HawVer schreef op 10 september 2002 @ 09:21:
[...]

Het is niet echt een bug. Maar als je je muis inhoud en vanaf het midden naar beneden beweegt sleep je één van de plaatjes eruit. Die verschijnd dan als enigste in het scherm

Dit is op zich zowiezo maar een testcase om te kijken of dit werkt, maar wat jij bedoelt is volgens mij gewoon standaard browser functionaliteit. Als je een plaatje naar je locatiebalk (of statusbalk) sleept komt er bij je muis zo'n +'je, als je dan loslaat opent je browser dat plaatje als "nieuw document"

killercow,
Die shot daar, hoe werkt dat ? is dat 1 (of meerdere) godsegrote tabel(len) met allemaal losse plaatjes? Lijkt het wel op namelijk. het ziet er wel uit

[crisp]

Clay schreef op 10 september 2002 @ 10:26:
[...]


Dit is op zich zowiezo maar een testcase om te kijken of dit werkt, maar wat jij bedoelt is volgens mij gewoon standaard browser functionaliteit. Als je een plaatje naar je locatiebalk (of statusbalk) sleept komt er bij je muis zo'n +'je, als je dan loslaat opent je browser dat plaatje als "nieuw document"

En is simpelweg te ondervangen met een onDragStart="return false"

killercow,
Die shot daar, hoe werkt dat ? is dat 1 (of meerdere) godsegrote tabel(len) met allemaal losse plaatjes? Lijkt het wel op namelijk. het ziet er wel uit

Inderdaad; ziet er echt uit, hoe is de performance?

[r0bert]

DiMension schreef op 22 augustus 2002 @ 00:09:
Speel hier maar mee totdat je een bug ontdekt

Da's alles wat we tnt hebben geloof ik

Het is niet echt een bug, maar als ik eerst een beetje ga lopen spelen en dan vervolgens de spatiebalk bijv 3 sec indruk, luisterd het veld niet meer, en gaat het zijn eigen leventje lijden/leiden

[killercow]

die shot zijn 50 layers gevuld met plaatjes, deze layers bevatten dus allemaal plaatjes met de zelfde x coordinaat en hoogte level anders past het niet, de images met andere hoogtes worden ondergebracht op andere layers, ik moet alleen nog het clicken van een plaatje en het affangen van de doorzichtige hoekjes uitvinden omdat je nu niet op het plaatje van je keuze klikt vanwege de z-index.

de performance is redelijk goed, het scrollen gaat op een athlon 700 met tnt2 aardig, maar dat is dan browser scrollen, het dhtml scrollen en het vissible en invissible maken van de plaatjes aan de hand van dhtml gaat nog soepeler.

deze test heb ik gedaan met een map van 2500 tiles (50x50) en 2500 layers vanwege dat hiden enzo.

ps weet iemand hier hoe je vectoren enzo doet?
dus hoe ik de lichtsterkte op een bepaald vlak kan uitrekenen?

[gitaarwerk]

btw... missschien een HELE late reacties.. maarreh... nog mensen nodig voor muziek / geluid? (creeer ik wat n me home studiootje)

[Apollo_Futurae]

• Nog even over de collision detection:

Zou het niet handig zijn om in een centraal grid te registreren welke tiles worden bezet (of snel gebruikt gaan worden door een unit)?
Elke unit moet dan in elke bewegingsiteratie het volgende doen:

(1) Bereken welke tiles nodig zijn vòòr de volgende iteratie/berekening.
Als hier tiles bij zijn die de unit niet nu al bezet, ga naar (2), zo nee, ga naar (4) (je zou misschien denken dat (4) niet uitgevoerd hoeft te worden, omdat de unit kennelijk op dezelfde tile blijft; maar misschien kan een unit met minder dan één tile per seconde bewegen?).

(2) Zoek in het centrale grid op of de gewenste tiles van (1) 'gereserveerd' zijn door een andere unit. Zo ja, ga naar (3), zo nee, ga naar (4).

(3) Voer de daadwerkelijke collision detection uit (uiteraard alleen met de units die bij (2) gevonden zijn). Collision? Ga naar (5). Geen collision? Ga naar (4).

(4) Registreer de gewenste en nieuw te bezetten tiles in het centrale grid en beweeg de unit.

(5) Doe een nieuwe AI request/voer een nieuwe pathfinding uit/knal het rotsblok omver .

Dit lijkt een hele lijst, maar valt in de praktijk denk ik nogal mee.

• Over de levels: mij lijkt een duidelijk gespecifeerd javascript (duh) objectmodel het beste. Levels kunnen dan uit *.js bestaan en gewoon geinclude worden. Deze *.js doet zelf niets (behalve declaraties van de vorm unit.setColor('red'); ). De engine vraagt vervolgens wanneer nodig die gegevens via hetzelfde objectmodel op.

• Aan de mensen die zeer genereus hun creativiteit ter misbruik aanbieden : alle inbreng is welkom. Knutsel lekker wat probeerseltjes in elkaar en gooi het hier neer ! Er is nog niet echt een geheel gevormd (alhoewel er ongetwijfeld op de achtergrond veel werk verzet wordt ) en wat plaatjes en muziekjes kunnen Snowstorm wat 'tastbaarheid' geven.

[UDuckling5]

Dit zag ik op de site http://www.xs4all.nl/~pet...nowstorm/overzichtje.html :

De meeste wapens zullen instant-hit zijn. Een unit die op een andere unit schiet zal dan ook per definitie raak schieten, en de damage zal dan afhankelijk van upgrades afgehandeld worden.

Kun je niet iets maken dat je een unit zoveel procent kans heeft om een andere unit te raken? En dat je na een upgrade van je unit meer procent kans hebt? Lijkt me realistischer en niet zo moeilijk te coden.

Evenzo met damage, als dat variabel is per schot, draagt dat ook weer bij aan het realisme en wordt het een tikkie onverwachter wat de uitkomst zal zijn. (de sterkste units HOEVEN dan dus niet altijd te winnen.)

Bovendien, ik ben een nieuwkomer hier, en het project spreekt me erg aan. Ik ga vanmiddag heel het topic even doorspitten om een beter beeld te krijgen.

Mijn coding skills zijn niet de moeite van het noemen waard, hetzelfde geld voor mijn grafische kunsten. Maar achtergrond verhaaltjes verzinnen, units bedenken (dus niet tekenen) of brainstormen over de gameplay lukt me wel.

[Clay]

Kun je niet iets maken dat je een unit zoveel procent kans heeft om een andere unit te raken? En dat je na een upgrade van je unit meer procent kans hebt? Lijkt me realistischer en niet zo moeilijk te coden.

Evenzo met damage, als dat variabel is per schot, draagt dat ook weer bij aan het realisme en wordt het een tikkie onverwachter wat de uitkomst zal zijn. (de sterkste units HOEVEN dan dus niet altijd te winnen.)

Prima idee. is ook niet moeilijk te implementeren gok/denk ik. Ik zal het er in de loop van vandaag ff bijzetten in het overzichtje

[Verwijderd]

Je moet verschillende unit types hebben om meer strategische elementen erin te gooien.
Light, Medium en Heavy ofzo
Zodat je bijv Light units kunt gebruiken die goed werken tegen heavy, maar wel erg slap zijn enzow

[David]

Verwijderd schreef op 12 september 2002 @ 15:35:
Je moet verschillende unit types hebben om meer strategische elementen erin te gooien.
Light, Medium en Heavy ofzo
Zodat je bijv Light units kunt gebruiken die goed werken tegen heavy, maar wel erg slap zijn enzow

Warcraft 3

Dat soort dingen zijn later nog te implementeren. Als we alle info in XML opslaan, kunnen we zelfs een soort van mods maken. Als we dan nog zorgen dat je extra .js-bestanden eraan toe kan voegen voor extra functies, is het helemaal mooi.

[UDuckling5]

In ieder geval al 9 soorten units Air, Ground en Sea, en dan elk onderverdeeld in heavy, light en medium. En nog Infanterie. En afweergeschut. En mechs. En ondersteuning vanuit een ruimtestation. En en en...

BTW: Moet het per sé op Starcraft lijken (nooit gespeeld...)? Anders wil ik wel een sci-fi verhaaltje schrijven, zodat het inhoudelijk ook goed wordt

edit:

3 smileys, waar moet dat heen...

[David]

Ik zou starcraft toch maar ff spelen. 'T is best wel sci-fi, maar wel met sfeer.

Het idee van light, medium en heavy staat mij niet heel erg aan. Je kunt units sowieso al eigenschappen meegeven als snelheid, armor en schietkracht. Kun je zelf kiezen wat tegen wat moet.

[r0bert]

Pelle (in begin van topic):
[..]
Laat ik wel voor 1 ding waarschuwen: als we te hoog inzetten, dan bloedt dit project dood wegens (ogenschijnlijk) onoverkomelijke problemen. Neem de /14 projecten als WASP, 3d engine enz.
[..]

-----------------------------------------------------------------

* r0bert gaat zich binnenkort ook maar eens in het topic storten, maar eerst nu als de bliksem naar school

[UDuckling5]

Ben nu de demo aan het downen.

*eigenlijk is dit gewoon een ordinair schopje*

[Clay]

* kick

Ik heb een testje gemaakt, ge-end op units, selectie en klikken, en die staat hier. Nou is mijn vraag of een paar mensen even de source een beetje kunnen bekijken of ze het eens zijn met deze opzet. Die zal ik kort ff toelichten,

het lijkt mij handig alles zo gestructureerd en helder mogelijk te houden (doh) vandaar dat alles vanuit het "engine" object geregeld wordt, de engine voegt op verzoek de player toe, en die kan weer units toevoegen. Er is een superclass Unit, die heeft een paar standaard methodes, en de "Marine" erft daar alles van over (en heeft op dit moment ook nix zelf specifiek, maar 't is maar een test). deze units hebben weer een Sprite object, voor de image (nu een kleur), en die Sprite is een dynObject uit beehive2, waarmee je dus redelijk wat <div> specifieke dingen kan uitvoeren. Dan zitten er nog wat globale muisdingen in, dat zou zo kunnen, maar het kan ook vast anders.
Dat Direction object wat ik gebruik zit in mathutils.js, en daarmee kan je gonio laten doen, dat zorgt dus voor de formatie in het rondje. Je kan de 5 "marines" aanklikken om ze te selecteren en ermee te "lopen", en nog een keer klikken om te de-selecteren.

Wat ik ook wou vragen is of iemand weet hoe je met een X en Y kan bepalen WELKE tile je aanklikt in het isometrische speelveld, daar moet een (standaard?) formule voor zijn, maar die heb ik nog even niet kunnen bedenken (samen met de conventie van hoe je je tiles "definieert")

[David]

Ik heb de source nog niet bekeken, zal ik zo even doen.
De units buggen nog wel flink. Sommige units willen niet overal naartoe. Als je 1 unit pakt en die tussen twee andere probeert te parkeren gaat dat erg moeizaam. Ook bewegen ze over een lange afstand sneller dan over een korte afstand.

[Clay]

Ja, sorry dat kan ik uitleggen. Een unit gaat niet heen waar je klikt, maar naar een punt met een bepaalde straal daarvandaan, is even voor het gemak. 1 geselecteerde unit gaat dus in hoek 0 (rechts) met straal 25, dus 25 pixels rechts van je muis. zoals normal bij meerdere zal ook een enkele geselecteerde unit die circel formatie proberen te doen.
Verder doet een unit er, waar je ook heen gaat, er nu (ook even voor het gemak) 1 seconde over. Dus hoe groter de afstand, hoe sneller die beweegt. Het gaat echt even puur om simpele selectie, en een beetje bewegen, maar voornamelijk code opzet. Code uitwerking (die jij dus een soort van terecht bugs noemt) zijn makkelijk aan te passen, maar die waren toch al niet bedoeld uiteindelijk zo te worden

[David]

Zoiets had ik al begrepen.

Over die tiles: kun je ze niet allemaal een ID geven waarin de X en Y-coordinaten aangeeft? Iets als id="x25y16" ofzo. Lijkt mij het handigst in gebruik (voor javascript en CSS).

[Clay]

Ja die tiles moeten wel een (wellicth dergelijke) id hebben om ze te identifyen, maar welke tile je met je muis bij zit moet puur op basis van de X en Y daarvan "berekend" worden, en aangezien het hele tilestelsel diagonaal loopt zit daar een formule achter waarmee je in combo met die id's tiles kan aanspreken (voor bv de collision). Ik zou dus alleen ff niet weten hoe ik de X en Y van de muis vertalen kan naar exact de id van de tile waar je boven zit.

[David]

Ik ga er even over nadenken. Er rolt vast wel iets uit.

[[eNeRGy]]

kan je niet ipv een id een position object maken en aan het object hangen ?

oTile.position = new Object();
oTile.position.x = 25;
oTile.position.y = 16;

lijkt mij mooier.

[Woudloper]

Clay:
Ik heb een testje gemaakt, ge-end op units, selectie en klikken, en die staat hier.

Ziet er goed gestructureerd uit Ik had het niet beter kunnen doen (echt niet)

Goed/Handig gedaan om de sprite ene DynObject te maken uit beehive2. Nu heb je echt gewoon alle mogelijkheden welke je met een sprite kan/wil gaan doen...

Dat Direction object wat ik gebruik zit in mathutils.js, en daarmee kan je gonio laten doen, dat zorgt dus voor de formatie in het rondje. Je kan de 5 "marines" aanklikken om ze te selecteren en ermee te "lopen", en nog een keer klikken om te de-selecteren.

Ik vroeg mij al af hoe je dat gedaan had met die formatie, maar zag (in de source) en las toen pas ook in jouw topic (Altijd eerst lezen hè ) Het is trouwens nog wel zo dat de sprites gewoon over elkaar heen gaan wanneer je ze naar een positie laat moven. Was dit expres of had dit te maken met het feit dat er anders teveel berekeningen (Lees: trager) uitgevoerd moesten worden?

Vanwaar trouwens de mogelijkheid om meerdere users toe te voegen Is dit omdat je de computer ook ziet als een user of is dit voor een mogelijke toekomstige multi-player oplossing??

Wat ik ook wou vragen is of iemand weet hoe je met een X en Y kan bepalen WELKE tile je aanklikt in het isometrische speelveld, daar moet een (standaard?) formule voor zijn, maar die heb ik nog even niet kunnen bedenken (samen met de conventie van hoe je je tiles "definieert")

Zo standaard is die functie niet naar mijn idee Ik (en ik hoop ook andere) denk er nog even over na, heb zo 1, 2, 3 geen oplossing....

[David]

Je moet het veld sowieso opdelen in rechthoekige vakken van 128 breed en 64 hoog (uitgaande van isometrische vlakken van 128 breed en 64 hoog). Door de X-positie te delen door 128 en de Y door 64 weet je in welke rechthoek je zit. Dan doe je X%128 (modulo) en Y%64 om de X en Y coordinaten in zo'n rechthoek te bepalen.
En toen ging ik gisteravond slapen, dus verder heb ik niet gedacht.

[André]

Clay:

Waarom doet dat testje het niet bij mij? De pagina geeft een fout in regel 196 char 2: "Object doesn't support this property or method".

Ik zit op win2k + IE5