[DHTML] Project "Snowstorm"

[Limhes]

Ik denk wel dat het aardig lastig wordt om het geheel werkend te krijgen. Ik ben zelf ff bezig geweest om de tank van hierboven rond te laten rijden, maar het blijft hier vrij buggy (stopt soms ineens of draait de andere kant op).
Ik zuig dan ook best wel met JS, en wat ik gemaakt heb is ook niet OO en af en toe vrij obfuscated

Klik

.edit: btw IE5.5+ ofzo

[Clay]

VML gebruiken lijkt me inderdaad trouwens wel een verrekte handig idee Dit zal qua code uiteindelijk toch wel zo bruut worden dat het nergens anders in draait dan in IE. MoZ en ns4(lol) gaan het toch niet trekken.

[Limhes]

Hoe wil je overigens twee tanks tegelijk laten rijden? Tanks in een tijdelijke array gooien en ze steeds na elkaar updaten ofzo?

[Clay]

nee, daar komt de OO kijken Een tank heeft als object een eigen interval die zijn positie update. Zo hoeven tanks dus ook niet op elkaar te "wachten" zoals dat in het geval van een for loop zou zijn, bij grotere aantallen tanks zou je dat wachten namelijk gaan merken.

wat wel kan is alle positieberekeningen van de units in 1 grote for loop gooien (of verdelen over enkele "threads" van loops, bijv zelfde typen units), maar de werkelijke verplaatsing van de unit-layer moet (voor lekkere performance en de mogelijheid om VEEL units te hebben) in een losse interval.

[Annie]

Op zondag 16 juni 2002 21:03 schreef Clay het volgende:
VML gebruiken lijkt me inderdaad trouwens wel een verrekte handig idee

Tja, alleen is het dan geen dhtml starcraft meer en daar ging het om.

[r0bert]

* r0bert wil even laten weten dat hij gezien de huidige projectjes die hij heeft liggen en het naderde betere weer waarschijnlijk niet echt actief zal zijn in dit topic

Het lijkt mij trouwens het beste om gewoon eerst een simpele basis op te zetten, met bijv 1 tankje welk goed (zonder bugs dus ) rijdt. En dan van daaruit steeds verder uitbouwen ipv meteen een map te willen maken waar je een onbeperkt aantal units kunt aanmaken, bewegen, controleren etc..

[Clay]

r0bert
Het lijkt mij trouwens het beste om gewoon eerst een simpele basis op te zetten, met bijv 1 tankje welk goed (zonder bugs dus ) rijdt. En dan van daaruit steeds verder uitbouwen ipv meteen een map te willen maken waar je een onbeperkt aantal units kunt aanmaken, bewegen, controleren etc..

Het toffe van OO is juist dat als je 1 unit defineert (en dat goed doet) je ook meteen een onbeperkt aantal kan aanmaken In groepen bewegen en controleren is idd wel een iets ander verhaal.
Is er anders behoefte aan een NL-tuto over OO js? misschien dat er iets via http://javascript.pagina.nl/ te vinden is (want er zijn wel zat tuto's), maar ik wil er ook best een maken anders.

Annie
[..]
Tja, alleen is het dan geen dhtml starcraft meer en daar ging het om.

Zit wat in ja, maar het is wel erg handig om units mee te draaien. En een unit zal hoe dan ook nog in een layer moeten zitten om um te bewegen e.d. Dus ik denk dat het vml gebruik (als we het toepassen) wel beperkt kan blijven. En anders moeten alle images onder een bepaald aantal vaste hoeken gemaakt worden, statisch en ge-animate, dat zouden met 8 hoeken dan al 16 plaatjes voor 1 unit worden...

[Bosmonster]

Op maandag 17 juni 2002 09:07 schreef Clay het volgende:

[..]

Zit wat in ja, maar het is wel erg handig om units mee te draaien. En een unit zal hoe dan ook nog in een layer moeten zitten om um te bewegen e.d. Dus ik denk dat het vml gebruik (als we het toepassen) wel beperkt kan blijven. En anders moeten alle images onder een bepaald aantal vaste hoeken gemaakt worden, statisch en ge-animate, dat zouden met 8 hoeken dan al 16 plaatjes voor 1 unit worden...

Das niet zo'n ramp, aangezien het toch een offline-spel wordt neem ik aan.. Anders zit je ook nogal beperkt aan je vormgeving en moet je overal pre-loaders in gaan zitten zetten. En in DHTML maken die de boel nu niet overzichtelijker..

Als het Ie-only wordt dan vinnik die filters (Zie Limhes voorbeeld) ook een aardig idee.

[Woudloper]

r0bert:
[..]
En dan van daaruit steeds verder uitbouwen
[..]

Zoals Clay net gezegd heeft is dat dus niet meer het probleem meer aangezien we gebruik maken van OO en dit nadat je dus één unit heb gemaakt het geen probleem meer is...

In principe gaan we momenteel de goede kant op....

• Map idee ligt er nu al (thanx to Clay)
  _{moet hier nog wel een eigen lay-out (grafx) voor worden gemaakt...}
• Bewegen van de bv. de tanks ligt al klaar (thanx to Limhes)
  _{Hoewel deze nog OO gemaakt moeten worden...}

'k Dacht dat dit wel zo de basis was waar we mee aan de gang zouden moeten gaan. Het één en ander moet nog worden geintegreerd....

Daarnaast moet er nog even goed worden gekeken naar de links welke gemeld zijn door oh,when?, dit omdat daar redelijk wat staat geschreven over hetgeen waar wij mee bezig zijn...

* Woudloper heeft wat artikeltjes gescand , maar heeft nog niet de tijd gehad om ze echt te lezen.... Ze zien er overigens wel interresant uit...

[Bosmonster]

Op maandag 17 juni 2002 09:22 schreef Woudloper het volgende:

[..]

Zoals Clay net gezegd heeft is dat dus niet meer het probleem meer aangezien we gebruik maken van OO en dit nadat je dus één unit heb gemaakt het geen probleem meer is...

In principe gaan we momenteel de goede kant op....

• Map idee ligt er nu al (thanx to Clay)
  _{moet hier nog wel een eigen lay-out (grafx) voor worden gemaakt...}
• Bewegen van de bv. de tanks ligt al klaar (thanx to Limhes)
  _{Hoewel deze nog OO gemaakt moeten worden...}

'k Dacht dat dit wel zo de basis was waar we mee aan de gang zouden moeten gaan. Het één en ander moet nog worden geintegreerd....

Daarnaast moet er nog even goed worden gekeken naar de links welke gemeld zijn door oh,when?, dit omdat daar redelijk wat staat geschreven over hetgeen waar wij mee bezig zijn...

* Woudloper heeft wat artikeltjes gescand , maar heeft nog niet de tijd gehad om ze echt te lezen.... Ze zien er overigens wel interresant uit...

No offence, maar ik denk niet dat dit bruikbare onderdelen zijn hoor Ten eerste is wat betreft coding/functionaliteit etc nog helemaal niks vastgelegd. Ten tweede zijn beide voorbeelden niet toesgespitst op de game. Clay's mapper is ok en ziet er strak uit, maar haalt het niet in grote maps ivm performance. Limhes stukje code implementeert geen pathfinding en is verder ook niet echt optimaal (al is het filter idee goed imho).

Dus Woudloper: Niet vooruit lopen op de feiten. Laten we eerst eens kijken hoe we dingen aan gaan pakken en optimaliseren en neem de voorbeelden niet als direct toepasbare components.

[Verwijderd]

Ik zou zeggen, kijk eerst of het allemaal wel haalbaar is Het idee is prachtig, maar het zou jammer zijn als je straks uren besteed aan een concept wat uiteindelijk vanwege performance grenzen niet haalbaar is

Qua scripting is het allemaal wel haalbaar Maar het moet niet zo zijn dat je straks 2fps haalt op een P4

[Verwijderd]

Het draaien van de units kun je gewoon doen door een aantal plaatjes van een unit te maken, en het plaatje aanpassen, afhankelijk van de richting?

Zo doen de meeste 2d RTS games dat ook, en dan hebben we helemaal geen VML of andere shit nodig.

[Clay]

Dat zal waarschijnlijk idd toch wel moeten. in isometrisch perspectief kan je ze ueberhaupt niet gaan draaien met vml, dan klopt je perspectief immers niet meer

Performance gaat echt wel lukken trouwens neem dit bijvoorbeeld 100 bacterien, waar best wel een bak gonio achter hangt per bacterie. Zoals ik een stuk terug beschreven heb is de werkelijke move van de layer losgehaald van de positieberekeningen, die gewoon in 1 grote for loop zitten.

[Verwijderd]

Op maandag 17 juni 2002 09:07 schreef Clay het volgende:

[..]

Het toffe van OO is juist dat als je 1 unit defineert (en dat goed doet) je ook meteen een onbeperkt aantal kan aanmaken In groepen bewegen en controleren is idd wel een iets ander verhaal.
Is er anders behoefte aan een NL-tuto over OO js? misschien dat er iets via http://javascript.pagina.nl/ te vinden is (want er zijn wel zat tuto's), maar ik wil er ook best een maken anders.
[..]

Zit wat in ja, maar het is wel erg handig om units mee te draaien. En een unit zal hoe dan ook nog in een layer moeten zitten om um te bewegen e.d. Dus ik denk dat het vml gebruik (als we het toepassen) wel beperkt kan blijven. En anders moeten alle images onder een bepaald aantal vaste hoeken gemaakt worden, statisch en ge-animate, dat zouden met 8 hoeken dan al 16 plaatjes voor 1 unit worden...

Goed taal-onafhankelijk OOP boek wat ik hier heb:
Object-Oriented Modeling and Design, uitgebracht door prentice hall.

[Bosmonster]

Op maandag 17 juni 2002 11:09 schreef B-Top het volgende:

[..]

Goed taal-onafhankelijk OOP boek wat ik hier heb:
Object-Oriented Modeling and Design, uitgebracht door prentice hall.

Javascript is niet echt Object-based, maar prototype-based. Daar zitten nog wel wat verschillen in. Maar goed.. de basis is altijd nuttig

[oh,when?]

Op maandag 17 juni 2002 11:13 schreef Bosmonster het volgende:

[..]

Javascript is niet echt Object-based, maar prototype-based. Daar zitten nog wel wat verschillen in. Maar goed.. de basis is altijd nuttig

Dat boek ken ik, is wel goed. En het gaat om het idee, implementatie van het idee in een taal is heel ander verhaal. Hoewel Javascript idd eigenlijk prototype-based is ipv class-based...

[Clay]

De definities van wat-based het is boeit me eigelijk niet zo als de nodige principes maar werken en objecten met hun object specifieke methoden + overerving werken (tot op zekere hoogte iig) dus * Clay is tevreden

[Verwijderd]

Ik ben tevreden als ik het gezoem van een Obelisk of Light in Dhtml terughoor, om vervolgens met oorverdovend gezoem mijn DopeHTML Commando te verliezen. The Horror!

[Limhes]

Ik stel mij trouwens beschikbaar voor het wiskundige gedeelte, vinnik wel leuk om te doen. En ik heb nooit starcraft gespeeld, dus het spel zelf bemoei ik me niet mee.

.edit: mijn tank rijdt nu redelijk stabiel. Ik was namelijk eerst bij de verplaatsing door aant rekenen met afgeronde variabelen Nu is er ook zo'n cool lijntje bij

[Verwijderd]

Op zondag 16 juni 2002 21:22 schreef Clay het volgende:
nee, daar komt de OO kijken Een tank heeft als object een eigen interval die zijn positie update. Zo hoeven tanks dus ook niet op elkaar te "wachten" zoals dat in het geval van een for loop zou zijn, bij grotere aantallen tanks zou je dat wachten namelijk gaan merken.

Dat is natuurlijk wel zo, maar als je het op deze manier doet en dus niet de posities dubbel opslaat (ook nog een groot raster waarin alle posities van alle objecten in staan en die ook real-time geupdate wordt) kun je dus niet tanks automatisch op een vijand laten schieten, of auto-turrets builden. Dat zal veel van de game-play afdoen, aangezien de playabilitie dan behoorlijk daalt.

Tenzij... je de objecten een bepaald raster (dat heel toevallig overeenkomt met danwel hun zichts- danwel hun schootsbereik) laat afzoeken naar andere objecten, maar ik denk dat dát veeeeeel meer overhead produceert dan alle objecten in een groot raster te gooien (om bijvoorbeeld de reden dat bijna alle objecten in meerdere van zulke rasters terecht komen, en bij massive-attacks () krijg je dan helemaal een enorme overhead), want ook deze rasters moeten om usable te zijn real-time geupdate worden.

BTW: dat real-time updaten kun je wellicht ook ietsje omzeilen, door een timeoutje, van zeg 100 ms (kan natuurlijk afhankelijk van wat qua playebility en performance wenselijk zijn aangepast worden)te maken die alle rasters update, dat is denk ik (maar das afhankelijk van de snelheid van de processor, denk ik) een lagere update-frequentie dan real-time.

In ieder geval erg veel suc6!

Just my 2 cents

edit: de welbekende typo

[Bosmonster]

Volgens mij is het niet zo'n performance-breaker om iedere unit z'n eigen "field of view" af te laten zoeken. Het is een loopje van slechts enkele griditems. Als je dit slim doet (lees: van binnen naar buiten) kun je ook stoppen zodra je de dichtsbijzijnde vijandelijke unit gevonden hebt en deze dus kunt aanvallen.

Dan lijkt het me wel het verstandigst per vrij hoge interval van bijvoorbeeld 1+ seconde. Dit maakt voor de gameplay niet zoveel uit, aangezien movement toch per tile gaat. Maar dit zorgt wel voor minder performanceverlies bij veel bewegende units dicht op elkaar in vergelijking met bijvoorbeeld afzoeken per wijziging.

Uiteraard kun je het dan ook nog zo doen dat units, nadat ze een auto-target hebben gevonden zich hieraan binden als in een gewone attack en dus het hele zoeken kunnen overslaan.

Uiteindelijk zal dat dus allemaal wel meevallen gok ik.

[Verwijderd]

Op maandag 17 juni 2002 17:10 schreef Bosmonster het volgende:
Volgens mij is het niet zo'n performance-breaker om iedere unit z'n eigen "field of view" af te laten zoeken. Het is een loopje van slechts enkele griditems. Als je dit slim doet (lees: van binnen naar buiten) kun je ook stoppen zodra je de dichtsbijzijnde vijandelijke unit gevonden hebt en deze dus kunt aanvallen.

Dat is inderdaad zo, maar het is niet altijd verstandig om het dichtsbijzijnde voertuig aan te vallen (om gelijk wat A.I. te koppelen), maar eerder het gevaarlijkste. Als het dan toch niet zo'n performance-breaker blijkt te zijn, kan je wellicht wel door laten zoeken en het koppelen met een tabelletje (multi-dimensionale array?) voor elk voertuigen een volgorde van gevaarlijkste tegenstanders. Het is niet zo heel moeilijk, maar maakt je units wel beduidend slimmer.

Dan lijkt het me wel het verstandigst per vrij hoge interval van bijvoorbeeld 1+ seconde. Dit maakt voor de gameplay niet zoveel uit, aangezien movement toch per tile gaat. Maar dit zorgt wel voor minder performanceverlies bij veel bewegende units dicht op elkaar in vergelijking met bijvoorbeeld afzoeken per wijziging.

Akkoord.

Uiteraard kun je het dan ook nog zo doen dat units, nadat ze een auto-target hebben gevonden zich hieraan binden als in een gewone attack en dus het hele zoeken kunnen overslaan.

Zie mijn verhaaltje boven, maar wat je trouwens wel kan doen, is dat zo gauw er een vijand gevonden is die bovenaan het lijstje met gevaarlijke ventjes staat, je inderdaad kan stoppen met zoeken.

Uiteindelijk zal dat dus allemaal wel meevallen gok ik.

Ik heb met zoveel layers en objecten nog geen ervaring (ik vermoed dat de meesten nog niet met zoiets massaals) dus de tijd zal het wijzen

edit: another typo bites the dust

[Verwijderd]

Over de game zelf, is het de bedoeling dat jezelf met 5 tanks, het opneemt tegen 5 tanks van de tegenstander oid !?

[Clay]

Bijvoorbeeld. En een leger marines, valkyries, enz. voordeel van de meeste weaponry is dat het instant hit is. bullets oid hoeven we dus niet veel te tracen maar da's allemaal later zorg.

[André]

Zo, ik ben ook weer aanwezig (nieuw huis). Wat een plannen hier, geweldig!

Count me ook maar in voor dit project.

Hoe gaan we het trouwens doen? Doet iedereen een stukje van de code ofzo? 1 de collision detection, 1 de graphics, 1 de pathfinding, enz...

* André is in ieder geval heel benieuwd naar het eindresultaat

[Verwijderd]

Op dinsdag 18 juni 2002 08:02 schreef Yogho het volgende:
Zo, ik ben ook weer aanwezig (nieuw huis). Wat een plannen hier, geweldig!

Count me ook maar in voor dit project.

Hoe gaan we het trouwens doen? Doet iedereen een stukje van de code ofzo? 1 de collision detection, 1 de graphics, 1 de pathfinding, enz...

/me is in ieder geval heel benieuwd naar het eindresultaat

Lijkt me eerder vestandig om eens heel erg goed op papier te zetten wat er nu precies in gaat komen en het ook echt te behandelen als een project

Tevens per te maken onderdeel bepalen wat de opties zijn qua technische mogelijkheden, en hier een optie uitkiezen.

Persoonlijk vind ik het helemaal geen probleem om met VML te werken Ook helemaal geen probleem als er zaken inkomen die via Flash lopen etc.

Lijkt me juist best mooi om een project af te leveren, welke diverse disciplines samenvoegen tot iets wat goed werkt

[André]

Op dinsdag 18 juni 2002 10:55 schreef Gordijnstok het volgende:

Persoonlijk vind ik het helemaal geen probleem om met VML te werken Ook helemaal geen probleem als er zaken inkomen die via Flash lopen etc.

Is VML niet verschrikkelijk langzaam? Ik kan me nog iets herinneren van een stukje VML wat ik ooit gemaakt heb dat gewoon niet meer te draaien was.

Dat was een pijl met een gradient die random heen en weer ging over het beeldscherm en die altijd je muiscursor aanwees. Maar bij meerdere pijlen was de performance-drop enorm.

Dus ik denk dat we dat eerst even moeten testen voordat we daar uberhaupt aan beginnen.

[Pelle]

Op dinsdag 18 juni 2002 10:55 schreef Gordijnstok het volgende:
Blah VML FLash enzo

Ik ben er wel fel op tegen. Dit is een DHTML project, en geen project dat een starcraft-versie gaat bouwen wat je toevallig in je browser af moet spelen.
* Pelle vindt: puur DHTML

Mocht het nog een keer tot een multiplayer versie komen, dan ontkom je waarschijnlijk niet aan Flash, maar ik vind het onzin om dat soort zaken bij een DHTML project te gaan betrekken.

[Clay]

vml roteren kunnen we niet gebruiken omdat het perspectief van een geroteerde unit niet klopt.

[edit]
dit bedoel ik:

[Bosmonster]

Op dinsdag 18 juni 2002 11:19 schreef Clay het volgende:
vml roteren kunnen we niet gebruiken omdat het perspectief van een geroteerde unit niet klopt.

[edit]
dit bedoel ik:

[afbeelding]

Daarom gewoon losse bitmapjes (GIF). Wordt dus pixelneuken voor de vormgevers, maar dat hadden ze waarschijnlijk al verwacht

[Woudloper]

Bosmonster:
Daarom gewoon losse bitmapjes (GIF). Wordt dus pixelneuken voor de vormgevers, maar dat hadden ze waarschijnlijk al verwacht

Even hierop doorborduren

Betekend het dan dat we met 4 of 8 richtingen gaan werken (of nog meer ), want dan moet er dus voor elke richting een andere iets in elkaar worden gepixelt...

[Limhes]

Maar dat betekent dus dat de units niet de goede richting op draaien voordat ze gaan bewegen

[Bosmonster]

Op dinsdag 18 juni 2002 12:24 schreef Limhes het volgende:
Maar dat betekent dus dat de units niet de goede richting op draaien voordat ze gaan bewegen

Das dus een nadeel van isometrisch (heeft niet mijn voorkeur, maar goed). Ik zie het zelf liever van bovenaf.

[BtM909]

Op dinsdag 18 juni 2002 12:15 schreef Woudloper het volgende:

Betekend het dan dat we met 4 of 8 richtingen gaan werken (of nog meer ), want dan moet er dus voor elke richting een andere iets in elkaar worden gepixelt...

Hoeft niet Ruben...

je hebt in principe maar 5 plaatjes nodig

[Limhes]

Op dinsdag 18 juni 2002 12:35 schreef BtM909 het volgende:
je hebt in principe maar 5 plaatjes nodig

Spiegelen mbv. filters?

[oh,when?]

Op dinsdag 18 juni 2002 11:09 schreef Pelle het volgende:

[..]

Ik ben er wel fel op tegen. Dit is een DHTML project, en geen project dat een starcraft-versie gaat bouwen wat je toevallig in je browser af moet spelen.
* Pelle vindt: puur DHTML

* oh,when? agrees..anders kunnen we net zo goed gelijk in Flash MX gaan werken.

[BtM909]

Waarom filters?

5 plaatjes maken en een aantal spiegelen.

[Woudloper]

BtM909:
je hebt in principe maar 5 plaatjes nodig

Je hebt gelijk.... Was te snel Was nl. in richtingen aan het denken....

[Limhes]

Op dinsdag 18 juni 2002 12:46 schreef BtM909 het volgende:
Waarom filters?

5 plaatjes maken en een aantal spiegelen.

Ik weet niet wat beter is qua performance, aparte plaatjes of spiegelen mbv filters (is maar beperkt mogelijk natuurlijk).

[Clay]

Op dinsdag 18 juni 2002 12:27 schreef Bosmonster het volgende:
[..]
Das dus een nadeel van isometrisch (heeft niet mijn voorkeur, maar goed). Ik zie het zelf liever van bovenaf.

Misschien dat ik er iets te makkelijk van uit ging dat we het ook werkelijk isometrisch gingen doen ik denk dat deze beslissing op zich nog gewoon open ligt, net als al het andere nog, maar ik ben zelf dus meer voorstander van isometrisch. Dat ziet er gewoon tien keer toffer uit, al is dat dus idd wel moeilijker.

Als we het isometrisch doen ben ik trouwens wel voorstander van losse plaatjes voor alle hoeken, en dat is veel werk ja maar liever geen js filters om de boel te draaien. Is er trouwens iemand die vette units zou kunnen moddelen in max/maya/oid ?

[Bosmonster]

Op dinsdag 18 juni 2002 13:48 schreef Clay het volgende:

[..]

Misschien dat ik er iets te makkelijk van uit ging dat we het ook werkelijk isometrisch gingen doen ik denk dat deze beslissing op zich nog gewoon open ligt, net als al het andere nog, maar ik ben zelf dus meer voorstander van isometrisch. Dat ziet er gewoon tien keer toffer uit, al is dat dus idd wel moeilijker.

Als we het isometrisch doen ben ik trouwens wel voorstander van losse plaatjes voor alle hoeken, en dat is veel werk ja maar liever geen js filters om de boel te draaien. Is er trouwens iemand die vette units zou kunnen moddelen in max/maya/oid ?

Isometrisch is wel cool, maar het heeft een aantal nadelen, ook in gameplay. Er zijn bijvoorbeeld delen waar je units niet zichtbaar zijn en je bent ook beperkt in movement van je units.

[Annie]

Op dinsdag 18 juni 2002 13:48 schreef Clay het volgende:
... losse plaatjes voor alle hoeken, en dat is veel werk ja

Tja, het kan natuurlijk niet zo zijn dat de dhtml goden weken/maanden/jaren ^{* Annie} aan het kloppen zijn. En de creatievere geesten in een middag klaar zijn

_{* Annie doorhalen wat niet van toepassing is}

[DeFeCt]

Op dinsdag 18 juni 2002 13:48 schreef Clay het volgende:
[..]
Is er trouwens iemand die vette units zou kunnen moddelen in max/maya/oid ?

Wat heb je aan vet gemoddelde units als je ze vervolgens op 10 bij 10 pixels gaat laten zien?

[Clay]

mwah, wordt wel iets groter maar da's juist een voordeel. Omdat het zo klein is hoeft het niet supergedetaileerd gemoddeld, en dan kan je veel makkelijker animated gifjes uit alle hoeken bakken. Lijkt me minder (of iig plezieriger) werk dan alle frames uit alle hoeken met de hand pixelen.

[Woudloper]

Clay:
mwah, wordt wel iets groter maar da's juist een voordeel. Omdat het zo klein is hoeft het niet supergedetaileerd gemoddeld, en dan kan je veel makkelijker animated gifjes uit alle hoeken bakken. Lijkt me minder (of iig plezieriger) werk dan alle frames uit alle hoeken met de hand pixelen.

Hoewel het mijn specialiteit is klinkt dit wel als de meest makkelijke manier om afbeeldingen vanuit meerdere hoeken te genereren...

Maar dan wel op pixelnivo, anders duurt het laden van de afbeeldingen zo lang of zie ik dat fout...

[oh,when?]

* oh,when? vind de inzending van Milov voor de the 5K contest wel het vermelden waard.

[drm]

woei

* drm was een paar dagen weg, en er is al weer heel wat gebrainstormed, hiero...

goed om te zien

Ik heb een paar dingetjes voorbij zien komen, waarvoor het misschien wel handig is, dat we eventjes knopen doorhakken.

• VML? Flash?
  Not done, imo. DHTML only.
• Perspectief?
  isometrisch perspectief is het mooist, en het leukst. Dus ik zou zeggen, give it a try. Als we er op een gegeven moment niet meer uitkomen, kunnen we altijd nog terug naar 2D.
• Grafix?
  Ben bang dat dat nog eventjes moet blijven bij testfiguurtjes, etc. Zodra de engine er ligt, kunnen we e.e.a. aan verhaal gaan bedenken (oid), en misschien wel een hele hoop werk aan unit-balancing, etc. maar dat is imo echt iets voor een volgende fase.
  _{Desalniettemin erg leuk wat ik al gezien heb}

Dus laten we iig voorlopig isometrisch perspectief aanhouden, aight?

[Bosmonster]

Op woensdag 19 juni 2002 10:14 schreef oh,when? het volgende:
* oh,when? vind de inzending van Milov voor de the 5K contest wel het vermelden waard.

wowser... je raakt pas echt verbaasd als blijkt dat die cave niet het enige level is

[Annie]

Op woensdag 19 juni 2002 10:14 schreef oh,when? het volgende:
* oh,when? vind de inzending van Milov voor de the 5K contest wel het vermelden waard.

* Annie hoopt wel dat bij dit project iets andere codeerstandaarden worden gebruikt
* Annie heeft in al zijn enthousiasme en als aanmoediging voor alle leden van het projectteam z'n ondertitel tijdelijk aangepast

[Clay]

Op woensdag 19 juni 2002 10:14 schreef oh,when? het volgende:
* oh,when? vind de inzending van Milov voor de the 5K contest wel het vermelden waard.

OMG! Dit is echt ULTIEM!

[Dries Arnolds]

Helemaal aan het eind van het tweede level. Die reflectie

[drm]

Annie:
* Annie heeft in al zijn enthousiasme en als aanmoediging voor alle leden van het projectteam z'n ondertitel tijdelijk aangepast

* drm vond dat wel een goed idee

_edit:
* drm heeft ook maar meteen een dark templar aan zijn random icons toegevoegd

[Arnim]

Cool, eindelijk Starcraft 2. Jammer genoeg weet ik te weinig van DHTML om mee te kunnen helpen (verder heb ik eigenlijk ook geen tijd). Voor het testen hou ik me wel aanbevolen.

Als dit allemaal echt van de grond komt, moet je wel oppassen voor het inbreken van de copyrights van Blizzard. Infoceptor heeft bijvoorbeeld de Starcraft to Warcraft 3 total conversion moeten stopzetten, omdat Blizzard ze ging aanklagen. Wellicht valt het allemaal wel mee, maar als je copyrighted materiaal gaat gebruiken, zou ik eerst toestemming vragen aan Blizzard.

http://www.infoceptor.com/war3tc/
http://www.blizzard.com/legalfaq.shtml

[Bosmonster]

wtf is Adun Toridas

[Verwijderd]

"Adun be with us"
[/offtopic :P]

[drm]

* drm digs the SC-ondertitel hype
</offtopic>

Arnim:
Als dit allemaal echt van de grond komt, moet je wel oppassen voor het inbreken van de copyrights van Blizzard.
[..]

Daar heb ik inderdaad ook al aan zitten denken. Maar in principe is 'DHTML Project "StarCraft"' gewoon een werknaam. Meer niet. Het is niet dat we het complete concept (inclusief units/artwork etc) gaan nabouwen, maar het meer het type spel wat we aanduiden. Ik kan me niet voorstellen dat Blizzard daar iets over kan, mag, of zelfs wil zeggen.

[Arnim]

Op woensdag 19 juni 2002 14:20 schreef drm het volgende:
Daar heb ik inderdaad ook al aan zitten denken. Maar in principe is 'DHTML Project "StarCraft"' gewoon een werknaam. Meer niet. Het is niet dat we het complete concept (inclusief units/artwork etc) gaan nabouwen, maar het meer het type spel wat we aanduiden. Ik kan me niet voorstellen dat Blizzard daar iets over kan, mag, of zelfs wil zeggen.

Dat er op zich nog niks beslist is en dat dit de werktitel is, had ik al wel begrepen. Blizzard kan inderdaad geen rechten leggen op RTS games. Let hier wel op hoe ver je gaat met het gebruik van Starcraft materiaal. Ik weet niet waar de grens ligt, maar misschien is het gebruiken van units met dezelfde namen als in Starcraft (Hydralisk, Zealot) al te veel van het goeie. Dat kun je beter van te voren uitzoeken dan op een gegeven moment achterkomen. Maar, je hebt er blijkbaar ook al aan gedacht.

[Bosmonster]

Op woensdag 19 juni 2002 14:37 schreef Arnim het volgende:

[..]

Dat er op zich nog niks beslist is en dat dit de werktitel is, had ik al wel begrepen. Blizzard kan inderdaad geen rechten leggen op RTS games. Let hier wel op hoe ver je gaat met het gebruik van Starcraft materiaal. Ik weet niet waar de grens ligt, maar misschien is het gebruiken van units met dezelfde namen als in Starcraft (Hydralisk, Zealot) al te veel van het goeie. Dat kun je beter van te voren uitzoeken dan op een gegeven moment achterkomen. Maar, je hebt er blijkbaar ook al aan gedacht.

Zolang we er geen commerciele bedoelingen mee hebben is er geen vuiltje aan de lucht volgens mij. Iedereen mag Starcraft nabouwen voor zichzelf, zolang je het maar neit gaat verkopen en er geld aan gat verdienene

Niet dat ik starcraft na zou willen bouwen.. integendeel, juist proberen zelf wat 'nieuws' te maken.

[Arnim]

Op woensdag 19 juni 2002 14:39 schreef Bosmonster het volgende:
Zolang we er geen commerciele bedoelingen mee hebben is er geen vuiltje aan de lucht volgens mij. Iedereen mag Starcraft nabouwen voor zichzelf, zolang je het maar neit gaat verkopen en er geld aan gat verdienene

Dat is wat vaak gedacht wordt en wat juist niet klopt! Kijk maar wat bv. Viacom doet om fansites te ontdoen van officieel Star Trek materiaal. Het is aan het bedrijf wat ze toestaan en wat niet. Blizzard is niet heel erg flauw, maar je weet niet wat ze van iets als dit gaan vinden.

[drm]

Arnim:
maar misschien is het gebruiken van units met dezelfde namen als in Starcraft (Hydralisk, Zealot) al te veel van het goeie.

Ik denk persoonlijk dat Blizzard dat niet eens erg zou vinden, zolang het idd werktitels zijn. Maar hydralisk en zealot zijn niet echt voor de hand liggende namen. Marine en Siege-tank misschien eerder (maar ik denk dat het dan gewoon 'tank' als werktitel zou zijn).

Eerder wanneer je echt artwork ofzo gaat jatten, dan zullen ze dat minder leuk vinden. Maar gelukkig zitten hier ook creatieve breinen die wat 'beters' kunnen verzinnen dan het jatten van Starcraft materiaal

Ik heb overigens cutter al gevraagd even hier naar te kijken. Die is wat beter los dit soort dingen.

Ik stel dus voor deze discussie eventjes te staken totdat hij er wat over geroepen heeft

(als je er legal docs over gevonden hebt, kun je die ook wel posten )

[Bosmonster]

Op woensdag 19 juni 2002 14:45 schreef Arnim het volgende:

[..]

Dat is wat vaak gedacht wordt en wat juist niet klopt! Kijk maar wat bv. Viacom doet om fansites te ontdoen van officieel Star Trek materiaal. Het is aan het bedrijf wat ze toestaan en wat niet. Blizzard is niet heel erg flauw, maar je weet niet wat ze van iets als dit gaan vinden.

Materiaal op fansites wordt dus wel geld aan verdiend. Denk aan banners. Ook dan is het commercieel gebruik van het materiaal.

[Pelle]

Op woensdag 19 juni 2002 14:20 schreef drm het volgende:
* drm digs the SC-ondertitel hype

* Pelle graaft in zijn geheugen

"You think as I do"
"Greetings Executor!"
"I love combat!"
"My life for Aiur"

Woei.. heb spontaan weer zin om te spelen

[drm]

Pelle:
Woei.. heb spontaan weer zin om te spelen

* drm 2
^</offtopic>

Zoals ik al min of meer vermoedde zei cutter het volgende:

^cutter@icq:
Mag denk ik gewoon niet. StarCraft zal wel een geregistreerde merknaam zijn. Als werknaam is het niet boeiend, verander het gewoon als er problemen komen. Ga er iig niet publiekelijk mee onder die naam, of je moet toestemming gaan vragen die je denk ik niet zult krijgen.

Dus, zolang het een werknaam is, geeft het niet, maar kunnen we uiteindelijk toch beter een andere naam ^{* drm} bedenken.

Ideeen?

_edit:
* drm lees: projectnaam

[Woudloper]

drm:
Dus, zolang het een werknaam is, geeft het niet, maar kunnen we uiteindelijk toch beter een andere naam bedenken.

Ideeën?

Voor de ideeën moeten we denk ik eerst wachten totdat we min of meer een verhaal hebben... Hoewel het nu wel zo is dat we weten welke kan we op willen....

Maar eh... _{(om toch maar een gooi te doen)}

• GoTCraft
• W&GCraft
• SpaceCraft
• en nog meer vervoeging met ...Craft

_{We kunnen natuurlijk ook helemaal van het ..Craft afwijken, maar dat lijkt mij niet logisch... Het is/was toch een beetje de basis..}

[André]

Command & GoTter

[Bosmonster]

W&G:Renegade

(ok ok geen RTS.. maar klinkt wel ok)

[drm]

Bosmonster:
W&G:Renegade

(ok ok geen RTS.. maar klinkt wel ok)

wtf heb jij nou weer voor icon
^</offtopic>

Project Snowstorm

bij wijze van @ Blizzard

[Woudloper]

Kan ik er nu vanuit gaan dat we momenteel aan het wachten zijn op het Plan van aanpak welke door Clay zal worden gemaakt

En dat we hiernaast nog gewoon bezig zijn met een (lange) brainstorm sessie over hoe we het één en ander gaan ontwikkelen

Als dat laatste zo is (* Woudloper gaat daar nu maar vanuit) dan wil ik nog even verder borduren...

Er is dus gekozen voor een isometrisch perspectief, maar in een eerder topic had Clay nog gezegd dat het wellicht handig zou zijn als hiervoor nog een test zou komen.

ik wil dus voorstellen hier een kleine test voor te bouwen enige punt is dan; wat worden de dimensies voor 1 ruit?

Hier is (naar mijn idee) nooit meer op gereageerd en om dat stukje van de brainstorm maar weer op te pakken lijkt het mij verstandig om verder te gaan met de laatste vraag

Daarnaast vindt ik de projectnaam Snowstorm, als van StarCraft --> Blizzard --> Snowstorm erg leuk gevonden... Moeten we nog even een modje vinden die de naame van het topic aanpast

Voor de codeerstandaarden lijkt het mij het beste om gewoon gebruik te maken van degene welke in de FAQ van P&W staan omdat deze redelijk generiek zijn en dus makkelijk gebruik kunnen worden voor JS/DHTML...

[drm]

Als ik over mezelf spreek, dan moet ik je helaas melden, dat ik bar weinig tijd heb, momenteel, en ik brainstorm hier en daar eventjes wat, en dan ga ik gauw weer verder met mijn werk ...

En wdb ben ik vast niet de enige. Dus imo hoeven we niet te stressen als e.e.a. hier en daar even uitgesteld wordt tot de weekenden wmb hebben we alle tijd

Daarnaast hoop ik binnenkort ff een gaatje te hebben om wat aan dat siteje te klooien, want dat gaat nu natuurlijk helemaal nergens over... (login en registratie module liggen d'r al, moet ik alleen ff implementeren, nieuwsposting systeempje, etc...)

Wel zo handig om de breakthroughs enzo bij te houden.

Maar goed, dat duurt nog wel ff want ik heb ook andere dingen aan mijn hoofd

[Bosmonster]

Ik weet niet hoe ik er mee door kan gaan in de toekomst.. Ons personeelsbestand is gisteren gehalveerd

Nu zat ik bij de 'goede' helft zeg maar, maar dit zal nog wel chaotische tijd worden.

[Woudloper]

drm:
Als ik over mezelf spreek, dan moet ik je helaas melden, dat ik bar weinig tijd heb, momenteel, en ik brainstorm hier en daar eventjes wat, en dan ga ik gauw weer verder met mijn werk ...

En wdb ben ik vast niet de enige. Dus imo hoeven we niet te stressen als e.e.a. hier en daar even uitgesteld wordt tot de weekenden wmb hebben we alle tijd

Helemaal gelijk, zo doe ik het ook.... En je bent zeker niet de enige

Daarnaast hoop ik binnenkort ff een gaatje te hebben om wat aan dat siteje te klooien, want dat gaat nu natuurlijk helemaal nergens over... (login en registratie module liggen d'r al, moet ik alleen ff implementeren, nieuwsposting systeempje, etc...)

Wel zo handig om de breakthroughs enzo bij te houden.

dat zal zeker handig zijn... Kunnen we zien wie op een bepaald moment met lagere prio werken dan de andere...

Bosmonster:
Ik weet niet hoe ik er mee door kan gaan in de toekomst.. Ons personeelsbestand is gisteren gehalveerd

No worries... Heb ik hier ook gehad (dan wel niet gehalveerd, maar wel wat weg). Het gaat vanzelf wel weer goed en de hectiek verdwijnt op den duur ook weer. Duurde bij ons ongeveer 2 à 3 weken....

[Bosmonster]

Op vrijdag 21 juni 2002 09:37 schreef Woudloper het volgende:

[..]

No worries... Heb ik hier ook gehad (dan wel niet gehalveerd, maar wel wat weg). Het gaat vanzelf wel weer goed en de hectiek verdwijnt op den duur ook weer. Duurde bij ons ongeveer 2 à 3 weken....

De situatie ligt hier toch wat gecompliceerder. Alle seniors zijn weg en hiermee complete support voor ons CMS. En als er geen nieuwe klanten bijkomen draait niks bij.

Bij het bedrijf waar mn vriendin werkte begon het ook met halvering.. en paar maanden later was het complete bedrijf pleitos. Dus zeker wel worries.

[drm]

Bosmonster:
[snip]

en nu ontopic

[Clay]

Snowstorm is een geweldige naam

Woudloper
Kan ik er nu vanuit gaan dat we momenteel aan het wachten zijn op het Plan van aanpak welke door Clay zal worden gemaakt

Plan is een groot woord ik zal iig proberen binnenkort een classemodel te bakken van hoe ik de structuur voor ogen zie.

En dat we hiernaast nog gewoon bezig zijn met een (lange) brainstorm sessie over hoe we het één en ander gaan ontwikkelen

Als dat laatste zo is (* Woudloper gaat daar nu maar vanuit) dan wil ik nog even verder borduren...

Er is dus gekozen voor een isometrisch perspectief, maar in een eerder topic had Clay nog gezegd dat het wellicht handig zou zijn als hiervoor nog een test zou komen.
[..]

Jah, een minimale test wil ik inderdaad daarvoor ook gaan maken.

Hier is (naar mijn idee) nooit meer op gereageerd en om dat stukje van de brainstorm maar weer op te pakken lijkt het mij verstandig om verder te gaan met de laatste vraag

Daarnaast vindt ik de projectnaam Snowstorm, als van StarCraft --> Blizzard --> Snowstorm erg leuk gevonden... Moeten we nog even een modje vinden die de naame van het topic aanpast

Snowstorm is imo ook een prima naam De game zal uiteindelijk denk ik ook een heel eigen rts worden, aangezien het niet op het origineel zal mogen lijken, en een eigen ding maken is denk ik ook tien keer leuker dan een bestaande game nabouwen.

Voor de codeerstandaarden lijkt het mij het beste om gewoon gebruik te maken van degene welke in de FAQ van P&W staan omdat deze redelijk generiek zijn en dus makkelijk gebruik kunnen worden voor JS/DHTML...

Inderdaad, aangezien we samen zullen moeten werken moet er ook een code conventie zijn waar iedereen zich aan te houden heeft, anders wordt het een zooitje. Daarnaast moeten er denk ik ook een aantal guidelines komen wat betreft dhtml specieke zaken, do's en don't's e.d.

Bosmonster
Ik weet niet hoe ik er mee door kan gaan in de toekomst.. Ons personeelsbestand is gisteren gehalveerd
Nu zat ik bij de 'goede' helft zeg maar, maar dit zal nog wel chaotische tijd worden.

Dat is inderdaad niet tof. Ik heb in deze trend een dik jaar geleden een faillisement meegemaakt (niet om je bang te maken btw) en dat zijn geen leuke dingen.

[drm]

Project Snowstorm it is, then...

Wat betreft code-conventies, wil ik wel even wat opzetten. Heb er al eerder wat dingetjes over geschreven, en ik denk dat mijn standaarden redelijk goed zijn.
_{(hell, de helft van de code-conventies uit de /14 faq komen bij mij vandaan )}
Overigens wil ik van te voren zeggen, dat ik niemand wil verplichten die conventies dan aan te houden (ikzelf kan "alles" lezen) maar het maakt 't wel prettiger.
_{'t zal mij een worst zijn welke indent-style je gebruikt, bijvoorbeeld}

Dos en don'ts mag iemand anders beetpakken...

* drm is overigens ook wel benieuwd naar een objectmodel

Daar heb ik vaak nog wel e.e.a. over op- of aan te merken

_{edit:
thnx to willem169 voor topictitle change}

[André]

Do's en dont's zijn wel belangrijk voor de leesbaarheid. Zoals indenten doe ik altijd met 2 spaties en nooit met ranzige tabs. En bij functies zet ik de accollade op de volgende regel:

code:

function Mooi()
{
  alert ("Mooi");
}

Voor dit soort dingen moet wel duidelijke richtlijnen zijn IMO.

[Verwijderd]

Op vrijdag 21 juni 2002 14:42 schreef Yogho het volgende:
Do's en dont's zijn wel belangrijk voor de leesbaarheid. Zoals indenten doe ik altijd met 2 spaties en nooit met ranzige tabs. En bij functies zet ik de accollade op de volgende regel:
[..]

Voor dit soort dingen moet wel duidelijke richtlijnen zijn IMO.

Ja, zoals:
- namen van functies beginnen met een onderkast
- namen van klassen beginnen met een kapitaal
- namen van constanten zijn opgebouwd uit louter kapitalen, en deelwoorden worden gescheiden met een underscore
- bij functie- of klassenamen die zijn opgebouwd uit deelwoorden, wordt eerste letter van elk volgende deelwoord een kapitaal

Etcetera , dat is toch het standaard systeem?

[Woudloper]

drm:
* drm is overigens ook wel benieuwd naar een objectmodel

Is het niet zo dat dit ook nog gedurende de brainstorm sessie (lees: thread) en gedurende het bouwen nog steeds verder uitgebouwd gaat worden. Ik denk eerst dat we de verschillende objecten moeten gaan identificeren voordat we ze daadwerkelijk eigenschappen gaan geven.

Men neme:

• Het spel zelf (1)
  - Map (2)
  - Eigen team (3)
  - Vijanden (3)
  - User (2)

Etc. etc... Dit is maar even wat ik zo één, twee, drie in gedachten had... Maar hier moet nog veel meer over ge-stormed worden....

_{/Edit: list in list lukt niet...}

[drm]

Cheatah, je spreekt mijn taal

In het kort mijn coding conventies, en ik stel voor dat we die aanhouden:

Wat betreft styling:

1. functienamen, methoden, properties en variabelen beginnen met kleine letter en zijn camelCased
2. klassenamen worden met grote letters begonnen en zijn eveneens CamelCased
3. underscores worden vermeden, behalve in constanten, die met UPPERCASE geschreven worden
4. Elke operator is omgeven door spaties
5. Elk haakje is omgeven door spaties, tenzij haakjes zijn leeg
6. Elke declaratie/definitie is verticaal uitgelijnd met dergelijke declaratie/definitie
7. Indent style volgende regel (Allman style)
8. indenten met 3 spaties (geen tab-characters)
9. Variabelen zijn nooit genummerd, maak er dan een array van
10. Namen van arrays zijn altijd meervoud
11. Elk non-compound statement wordt afgesloten met een ;
    ^{nee, dat is niet verplicht in JS}
12. bodies van een if, for, while, etc. zijn enkel compound statements wanneer nodig. Als er maar 1 statement is wordt die gewoon als body meegegeven zonder accollades.
13. Enkelregelig commentaar altijd met //
14. Meerdere regels commentaar alleen bij functies/classes
15. Enkelregelig commentaar (wanneer op dezelfde regel als statement) verticaal uitlijnen met ander commentaar
16. (diep) geneste functies altijd nieuwe regel + indenten

voorbeelden:

code:

function MyClass ( argument, anotherArgument )
{
   var   property,
       anotherProperty;

   this.property       = argument;
   this.anotherProperty  = anotherArgument;
}

function sjaak ()
{
   var     variabeles    = new Array (),
         alsoVariables    = new Array ();
   
   variables [  0 ] = 'sjaak';          // melpje
   variables [ 12 ] = new MyClass ();      // lerpje
   
   alsoVariables [   0 ] = /^[a-z]$/;       // oepsje
   alsoVariables [ 169 ] = /^[0-9]$/;       // bevertje
}

if ( conditie )
{
   statement ( 1 );
   statement ( 2 );
}
else
   statement ( 3 );

switch ( var )
{
   case 1:

   break;
   case 2:

   break;
   case 3:

   break;
   default:

   break; 
}

// geneste functieaanroepen:
functie1 (
   functie2 (
    functie3 ( var ),
    functie4 ( var )
   ),
   functie5 ( var )
);

Zoiets... Op- of aanmerkingen welkom natuurlijk. 't Is wmb geen wet van meden en perzen, maar 't is wel een begin.

Wat betreft commentaar bij functies mag iemand anders even zijn/haar emoties laten losbarsten.
* drm = kruk in commentaar

_edit:

Woudloper:
Ik denk eerst dat we de verschillende objecten moeten gaan identificeren voordat we ze daadwerkelijk eigenschappen gaan geven.

Daar is het een model voor Je kan wel eeuwig blijven brainstormen, maar daar schiet je niets mee op. En ik heb wdb alle vetrouwen in Clay.

_{/Edit: list in list lukt niet...}

• Oh

1. <li> nee?

</li>
• Bij mij

1. <li> gaat 't best

</li>
• aardig

[Pelle]

Op vrijdag 21 juni 2002 15:01 schreef Woudloper het volgende:
_{/Edit: list in list lukt niet...}

Niet?

• <li>bij<li>mij[list=a]<li>lukt<li>het<ol type="I"><li>echter [/list]<li>prima</ol><li>hoor ;)

Op vrijdag 21 juni 2002 15:22 schreef drm het volgende:
In het kort mijn coding conventies, en ik stel voor dat we die aanhouden:

Hmm

<li> Elk haakje is omgeven door spaties, tenzij haakjes zijn leeg

</li>

Dat vind ik persoonlijk dus zuigen.

<li> indenten met 3 spaties (geen tab-characters)

</li>

4 spaties is toch standaard?

Verder was ik het er helemaal mee eens
Oh ja, maar dat wist je ook al:

code:

function blab()
{
    // dit zuigt
}

function spef() {
    // dit roelt
}

Anyhoet, ik kan me er prima in vinden hoor, alleen de puntjes die ik hierboven noem zijn min of meer de enige waar ik het niet mee eens ben, doch zijn niet onoverkomelijk

* Pelle vind het mooi dat dit soort dingen alvast worden afgesproken

/edit
Overigens, ik zit me nu te bedenken.. het oorspronkelijke idee was toch dat iedereen een stukje code voor z'n rekening nam, en zich daarbij hield aan pre- en postcondities? Als dat zo is, dan maakt het geen fuck uit welke code-conventie je gebruikt; anderen zullen namelijk toch niet aan jouw code gaan werken... of zeg ik nu domme dingen?

[Clay]

ik vind ook dat

code:

function blab()
{
   // dit zuigt
}

function spef() {
   // dit roelt
}

als meer mensen dat nou ook vinden ...

[André]

ik vind ook dat

code:

function blab()
{
   // dit roelt
}

function spef() {
   // dit zuigt
}

als meer mensen dat nou ook vinden ...

[Clay]

POLL!!

Nah, maar het lijkt mij iig wel handig dat iedereen zich inderdaad aan dezelfde conventie houdt. Ook al hoef je voor je eigen deel misschien alleen maar rekening te houden met input en output richting andere classes.

Die spaties vind ik wel suf dat worden er namelijk een heleboel en dan ben je tientallen K's aan spaties aan het inladen als je de game online gaat spelen

[McVirusS]

ik vind ook dat

code:

function blab()
{
   // dit zuigt
}

function spef() {
   // dit ruled
}

Is altijd eerste wat ik verbeter als ik andermans code moet editten.

[drm]

Ik vind het allemaal prima, hoor. Zoals ik al zei, ik kan alles lezen. Het zijn enkel de conventies die ik zelf aanhoud, maar ik kan me prima vinden in jullie commentaar.

Dus aanpassingen in punten 4,5 en 7

nog meer?

dan klop ik zo ff een nieuwe in elkaar

_{overigens kan ik voor mezelf niets meer veranderen aan die spaties. Dat ben ik gewend sinds ik op school een keer die conventies ongeveer dergelijk aangesmeerd kreeg van iemand die bij een bedrijf die conventies geleerd had. Sindsdien heb ik de snelste spatie-duim van het hele westen}

McVirusS:
Is altijd eerste wat ik verbeter verander als ik andermans code moet editten.

_edit:
Nog iemand die inhoudelijke JavaScript dos en don'ts op wil stellen? Bijvoorbeeld

1. gebruik altijd document.getElementById ( .. ) ipv document.all [ .. ]

[Bosmonster]

Amen Clay!

Ik vind het ook! Das twee

• gebruik altijd document.getElementById ( .. ) ipv document.all [ .. ]

Gebruik ze geen van beiden (tenzij echt niet anders kan), maar sla je objecten op in een eigen Array bij creatie.. ongeveer factor 100 sneller ofzo

getElementById is wel ook 2x sneller dan document.all. dus die laatste is sowieso al taboe..

[drm]

Bosmonster:
eigen array

Ik gaf mijn bek ook maar een zet

[Verwijderd]

Gebruik common sense ipv conventies Dat voorkomt een hoop gezeik.

[Bosmonster]

Op vrijdag 21 juni 2002 21:43 schreef Gordijnstok het volgende:
Gebruik common sense ipv conventies Dat voorkomt een hoop gezeik.

Alleen jammer dat iedereen z'n common sense iets anders zegt

Vandaar de conventies.. dat scheelt een hoop gezeik.

[Verwijderd]

Is er al een soort van klassenmodel ?

[Clay]

klassemodel = groot woord Ik had iig wel iets in mijn hoofd zitten:



Player lijkt me duidelijk. De computer is een subclass daarvan. Een player heeft entities, en dat zijn of units, of buildings, met daaronder dus weer de subclassen daarvan (tank, marine, pyro, ghost, oid). Entities kunnen in een group zitten, voor makkelijke selectie.
Verder ben ik nog niet

[Annie]

btw. over zuigen gesproken
hier klopt natuurlijk helemaal niets van

code:

switch ( var )
{
   case 1:

   break;
   default:

   break; 
}

dit is al beter (en dan bedoel ik de positie van break; natuurlijk).

code:

switch (var) {
   case 1:
    // doe iets
    break;
   default:
    // doe iets anders
    break;
}

compromis voor het curly-braces "probleem"

code:

function doSomething()
{
   if (this && that) {
    // moehmoeh
   } else {
    // blabla
   }
}

[likkepot]

Ik weet dat het vervelend is dat ik dit vraag, aangezien ik niet echt meedoe in dit topic.

Moeten er nog graphics gemaakt worden ?
zoja ? Wat zijn de voorwaarden ?

[Clay]

Op zondag 23 juni 2002 17:22 schreef likkepot het volgende:
Ik weet dat het vervelend is dat ik dit vraag, aangezien ik niet echt meedoe in dit topic.

Moeten er nog graphics gemaakt worden ?
zoja ? Wat zijn de voorwaarden ?

Jah, er moeten ook graphics gemaakt worden, maar daar zijn:

• a: we nog niet aan toe
• b: nog geen specs voor

Komt dus nog.

FF een vraag/opmerking/idee. Persoonlijk vind ik het handig om bij dhtml een library te gebruiken, en dat wou ik graag hierbij ook zo doen. Aangezien er over standaard routines gebruikt moeten worden ala layers verplaatsen, showen hiden, clippen e.d. en gezien het feit dat dit een ongeloveljk complex ding wordt als het van de grond komt.
Overal en nergens losse document.getElementById(layer).style.attribuut = waarde; in de code draagt imo niet bij aan de duidelijkheid, maar er valt natuurlijk ook weer wat te zeggen voor "libraries zijn groot en bevatten veelal niet gebruikte dingen"

Daarom ben ik begonnen (en heb inmiddels een draaiende alpha) aan (codenaam)"BeeHive2". Deze is DOM only, werkt op dit moment gegarandeerd in IE6 en Moz (ie5 nog niet getest), en is 3 keer zo snel als BeeHive zelf. Ter illustratie, deze alpha kan in 1.6 seconden 1.000 layers genereren, (en onder de minuut 10.000), tegen 4.2 seconden van BeeHive voor 1.000 layers.
Vrijwel alle (>90%) huidige BeeHive functionaliteiten zitten erin,
en daarnaast kan die ook layers fysiek verplaatsen van nesting naar een andere nesting, en ook volledig verwijderen, en dat alles in op dit moment 5.7 K. (zo'n 3 keer zo klein ook dus)

enige wat mist zijn docs, en dat is toegegeven een beetje een probleem

Vraag is dus, is er iemand op tegen dit te gebruiken, (en zoja waarom, naast het gemis aan docs)?

[Bosmonster]

Op dinsdag 25 juni 2002 12:44 schreef Clay het volgende:

[..]

...lang en interessant verhaal van Clay...

Geef 'ns.. ff kijken of er nog wat aan te tweaken valt

[drm]

Clay: [BeeHive2]

ik heb er niets op tegen. Ga maar gauw aan de slag met documentatie

[Verwijderd]

_{subtiel schopje}

[drm]

* drm kan alvast verklappen voorlopig geen tijd te hebben

[LuCarD]

Clay: [BeeHive2]

Is hier al wat meer over bekend???

[Woudloper]

* Woudloper is net een hele week ziek geweest en zit net twee tellen weer achter zijn laptop

Volgende week nog 4 dagen de tijd en dan ben ik 3 weken op vakantie... Eind juli weer terug....

_{Gaat mijn beeldscherm nou zo heen en weer of ben ik het zelf...}