[DHTML] Project "Snowstorm"

[Explore]

Ik ben er doorheen. het viel me op dat er een lange discussie gaande was/is over collision detection van units, terwijl mijn inziens dat helemaal niet van belang is. Het lijkt me verstandig deze post van Apollo_Futurae in de gaten te houden (waar volgens mij niemand op gereageerd heeft). Voor zover ik zijn uitleg begrijp legt hij uit dat je niet alle units continu alle mogelijke collisions hoeft uit te laten rekenen (zoals nog steeds in de samenvatting van Clay staat). Dit komt de optimalisatie wel ten goede.

Hoe zit het verder met het groeperen van units? Dus een kadertje om een aantal units trekken en deze als groep definieren. Moet toch niet al te moeilijk zijn...

Niemand heeft nog de mogelijkheid ter sprake gebracht van een klein overzichtskaartje, waarop alles te zien is - een soort van navigator, zeg maar. Ik heb Starcraft ook nog nooit gespeeld, maar ik ken wel de meeste andere clones (C&C, Red Alert, etc.) en die hebben allemaal zo'n overzichts kaart. Je kan dan je group selecteren en op het kleine kaartje klikken om ze daar naartoe te sturen. Je hoeft dan niet op het speelveld zelf de bestemming te zoeken en zo het overzicht te verliezen. Best wel cruciaal in zo'n spel als dit.

Is het veld waar je nog niet geweest bent hidden (zwart zeg maar) en wordt het pas bekend als je er geweest bent met een scout-unit ofzo? Of is heel het speelveld meteen zichtbaar?

Het lijkt mij inderdaad belangrijk om een paar dingen af te spreken. Gooi er voor mijn part een poll tegenaan.

Dingen als:

1. hoeveel spelers in 1 veld (1 persoon, x computer)
2. drie types units: voetvolk, rijdende units en vliegende units
3. van die drie types zijn er weer verschillende soorten:
- voetvolk: infanterie, bommenwerpers, verkenner, spion, etc... (voor de verhaallijnbedenkers)
- rijdend: tank, auto's, etc...
- vliegend: je raad 't al.

Ook al zijn dat soort dingen niet per definitie van belang voor de werking van het spel. Het is al wel goed dat dat soort dingen (ergens ooit een keer) vast komen te staan, zodat iedereen een beter beeld heeft van de richting waar het heen gaat.
Zo moeilijk is het toch niet om dit soort besluiten te nemen?

Vergeet niet dat pathfinding een vrij intensief rekenwerkje is. Voor elke unit die van A naar B gaat moet zo'n path-berekening worden uitgevoerd en onderweg hoogstwaarschijnlijk herberekend, aangezien een spel dynamisch is. Bijvoorbeeld: Als een unit van de speler van A naar B wordt gestuurd, dan kan het zijn dat een computer speler - terwijl die unit onderweg is - op het pad een gebouw neerzet of een grote groep tanks. Zie hierover weer de post van Apollo_Futurae.

Wellicht ga ik morgen even freaken met het selecteren van een groep. Ik heb alleen nog nooit met Beehive gewerkt, dus ik zal 't wel op m'n eigen methode oplossen (als iemand anders me niet voor is).

[Verwijderd]

Is dat warcraft-style? Nee? Hoeft niet

Ik geloof dat ze alles van starcraft wouden jatten gebruiken... Maar lekker botje hoor .

Starcraft ventjes heb anders nog wel liggen



*bunker is ook beschikbaar

[Explore]

Goed, ik heb een unit-selectie demotje gemaakt, welke hier te vinden is. Er zitten nog wat bugs in, zoals te verwachten is, maar het plan is er. Nu staan er 25 'units', wat wel lekker werkt. Maar bij meer units, ca. 100 ofzo, begint het al vrij heavy to worden. Ik denk wel dat er het eea. valt te optimaliseren aan het stukje code wat kijkt of een unit in het selectie window valt...

[David]

Explore schreef op 13 oktober 2002 @ 15:21:
Goed, ik heb een unit-selectie demotje gemaakt

Hij werkt niet in Mozilla. Ik denk dat dat wel een belangrijke issue is.

[Explore]

DiMension schreef op 13 oktober 2002 @ 17:33:
[...]


Hij werkt niet in Mozilla. Ik denk dat dat wel een belangrijke issue is.

Ik zie hier voornamelijk staan dat het een IE-only project wordt. Maargoed, de voornaamste reden dat het niet in Mozilla werkt is vanwege het gebruik van attachEvent - Mozilla kent dat niet. 't Is niet echt een issue, valt zo te fixen. Het gaat meer even om het idee.

[David]

We zijn van plan een W3C-standaards compatible game te maken. In Mozilla moet het dus sowieso kunnen werken.

[Clay]

Mithrandir schreef op 12 oktober 2002 @ 20:56:

Ik geloof dat ze alles van starcraft wouden jatten gebruiken... Maar lekker botje hoor .

Ik leef in de veronderstelling dat alle graphics zelf gefabriceerd gaan worden, nix "geleend" van bestaande games dus

Die selectie demo is erg cool En wat mozilla betreft is dat niet zo erg, want omdat het imo extreem belangrijk is dat alles modulair en transparant wordt opgezet komt er een grafische onderlaag die alle browserspecifieke dhtml dingen overneemt. een layer (sprite) beweeg je dus niet met ding.style.left.... maar met sprite.moveTo(), die moveTo zorgt dan wel dat het overal in werkt.
Idem voor events; Omdat er waarschijnlijk een oerwoud aan mouse (en andere) event handlers moet komen kan je niet met document.onmousemove = .... iets aan de muis gaan koppelen wanneer je dat nodig hebt, dat zou immers alle vorige mousemove handlers overschrijven. Dat zal dan met iets ala document.attachEvent("eventtype", referentie); gaan. Dit (het is niet de IE attachEvent, maar een gescripte) voegt die referentie TOE aan de bestaande lijst van eventhandlers die op dat tiepe moet reageren, en voert ze dus allemaal uit, zodat je eindeloze handlers op 1 event kan zetten (ook "onload").

Het enige wat ik wel zou veranderen aan die selectie is hem niet ondrag de selectie laten zoeken, maar onmouseup, puur voor de "optimalisatie".

Is het veld waar je nog niet geweest bent hidden (zwart zeg maar) en wordt het pas bekend als je er geweest bent met een scout-unit ofzo? Of is heel het speelveld meteen zichtbaar?

Fog of war is in principe natuurlijk ook belangrijk dat zou je kunnen doen door de tiles die je nog niet gezien heb gewoon zwart te maken (nog een laag eroverheen leggen is denk ik overkill) en alles wat daar aan layers in zit op hidden te zetten, of je kan het gewoon zo doen dat je als speler je view niet verder dan een dX en dY van je eigen units vandaaan mag doen.

1. hoeveel spelers in 1 veld (1 persoon, x computer)

Ik dacht inderdaad dat het puur single player ging worden, en wat de computer betreft, die moet in principe 100% Object based/oriented worden zodat het technisch niet uit maakt of je als speler nou 1 of 10 computers tegen je hebt. In je code definieer je het prototype, het aantal instanties moet vrij zijn.

hey, ik lees dit ook voor het eerst, moet zeggen leuk idee, ik hoop dat er wat uitkomt. Nou weet ik nix van java/etc. maar wel van plaatjes maken. Zo heb ik nog wat "untits" op mijn schijf staan, die jullie best mogen gebruiken. Ik weet dat jullie nog lang niet bij het grafische gedeelte zijn, maar misschien heb je er 1tje nodig als test versie ofzo, dunno. Iig wil ik best eens wat isometrisch uitrenderen etc.

whoa!
Is het "makkelijk" om dat inclusief loop/shiet animatie in animated gifs te renderen? of ernaar om te zetten met wat handwerk?

[Woudloper]

Explore:Ik ben er doorheen. het viel me op dat er een lange discussie gaande was/is over collision detection van units, terwijl mijn inziens dat helemaal niet van belang is. Het lijkt me verstandig deze post van Apollo_Futurae in de gaten te houden (waar volgens mij niemand op gereageerd heeft). Voor zover ik zijn uitleg begrijp legt hij uit dat je niet alle units continu alle mogelijke collisions hoeft uit te laten rekenen (zoals nog steeds in de samenvatting van Clay staat). Dit komt de optimalisatie wel ten goede.

Gelukkig dat je er hemelaal doorheen bent geworsteld Eigenlijk moet de samenvatting of de website van drm ook weer verder worden uitgebreidt, maar ja...

Verder maak je een goed punt met betrekking tot dit posting van Apollo_Futurea. Het is ook nog zo dat dit geheel nog steeds openstaat en zo, want we gaan pas écht verder als Beehive(2) (en natuurlijk de daarbij behorende documentatie )

Niemand heeft nog de mogelijkheid ter sprake gebracht van een klein overzichtskaartje, waarop alles te zien is - een soort van navigator, zeg maar. Ik heb Starcraft ook nog nooit gespeeld, maar ik ken wel de meeste andere clones (C&C, Red Alert, etc.) en die hebben allemaal zo'n overzichts kaart. Je kan dan je group selecteren en op het kleine kaartje klikken om ze daar naartoe te sturen. Je hoeft dan niet op het speelveld zelf de bestemming te zoeken en zo het overzicht te verliezen. Best wel cruciaal in zo'n spel als dit.

Dit klinkt wel grappig en ik heb hier ook mee lopen spelen, maar is het niet zo dat dit ook voor meer performance zorgt Persoonlijk zie ik dit als een feature (mogelijke toekomstige toevoegingen...) en heeft het (in mijn ogen) nog geen prioriteit, maar wellicht dat andere hier anders over denken...

* Woudloper is wel te overtuigen hoor, kom maar met goede argumenten...

Is het veld waar je nog niet geweest bent hidden (zwart zeg maar) en wordt het pas bekend als je er geweest bent met een scout-unit ofzo? Of is heel het speelveld meteen zichtbaar?

Het lijkt mij inderdaad belangrijk om een paar dingen af te spreken. Gooi er voor mijn part een poll tegenaan.

Liever discuseren wat mij betreft Ik heb het niet zo op de polls, je kan beter een telefonische enquete doen, is de response namelijk hoger e.d.

Vergeet niet dat pathfinding een vrij intensief rekenwerkje is. Voor elke unit die van A naar B gaat moet zo'n path-berekening worden uitgevoerd en onderweg hoogstwaarschijnlijk herberekend, aangezien een spel dynamisch is. Bijvoorbeeld: Als een unit van de speler van A naar B wordt gestuurd, dan kan het zijn dat een computer speler - terwijl die unit onderweg is - op het pad een gebouw neerzet of een grote groep tanks. Zie hierover weer de post van Apollo_Futurae.

Klopt, maar mijn inziens was jou idee over zo'n overall kaart t.b.v. unit selectie ook al vrij insentief v.w.b. het rekenwerk...

[Woudloper]

Clay:Ik leef in de veronderstelling dat alle graphics zelf gefabriceerd gaan worden, nix "geleend" van bestaande games dus

My points exactly

Die selectie demo is erg cool

Dat vond ik ook, werkt perfect... Nu alleen nog even zorgen dat deze ook gebruikt kan worden binnen Beehive(2) ....

Interresant verhaal over het attachen van events...

Wellicht dat we deze stelling (c.q. aanname) kunnen opnemen in het samenvattingen documenten, etc... Ik heb het gevoel dat hier meer een meer behoefte aan is aangezien het veel werk kost om de gehele thread door te lezen! Zie maar hoe lang Explore ermee bezig is geweest....

Fog of war is in principe natuurlijk ook belangrijk dat zou je kunnen doen door de tiles die je nog niet gezien heb gewoon zwart te maken (nog een laag eroverheen leggen is denk ik overkill) en alles wat daar aan layers in zit op hidden te zetten, of je kan het gewoon zo doen dat je als speler je view niet verder dan een dX en dY van je eigen units vandaaan mag doen.

Hier heb je vaker over nagedacht 'k was er zelf nog over na aan het denken hoe je dit op kon lossen, maar een goed punt...

Ik dacht inderdaad dat het puur single player ging worden, en wat de computer betreft, die moet in principe 100% Object based/oriented worden zodat het technisch niet uit maakt of je als speler nou 1 of 10 computers tegen je hebt. In je code definieer je het prototype, het aantal instanties moet vrij zijn.

Single Player Tenminste ik dacht dat die knoop al eens was doorgehakt

whoa!
Is het "makkelijk" om dat inclusief loop/schiet animatie in animated gifs te renderen? of ernaar om te zetten met wat handwerk?

Lijkt mij ook wel handig om het daarin (animated gif) weg te werken.... Quea performance e.d. is dat wellicht een goede oplossing...

[killercow]

Explore schreef op 12 oktober 2002 @ 23:59:
[...]


Die shots zijn inderdaad

Is die vraag al beantwoord? Is op zich niet ZO moeilijk, namelijk.

Lichtsterkte op een vlak is evenredig met de hoek die het invallende licht maakt met de normaal vector van het vlak: hoe kleiner de hoek des te groter de lichtsterkte en omgekeerd.

Maar hier was je waarschijnlijk allang achter...

Ik weet niet of dit offtopic is voor dit project.
Lijkt me wel een beetje 'over the top'.

iid daar was ik al achter maar ik kom voor geen meter verder
de rest schiet al aardig op maar zonder alle tiles kan ik niet beginnen met het genereren van maps, zelfs nemesis (world generator) draait al aardig alleen kan ik nu nog steeds alle tiles met de hand gaan lopen fizen en dat zuigt.

zou jij met hands-on willen helpen? via msn / ftp oid?
dan kan ik namenlijk die techniek uitbreiden en eventueel klaar maken voor gebruik in snowstorm.

[drm]

[nohtml]

Woudloper:
Gelukkig dat je er hemelaal doorheen bent geworsteld Eigenlijk moet de samenvatting of de website van drm ook weer verder worden uitgebreidt, maar ja...

jajaja, got the hint

even ter verduidelijking: 't Komt eraan

[Explore]

drm schreef op 14 oktober 2002 @ 11:57:
[nohtml]
[...]

jajaja, got the hint

even ter verduidelijking: 't Komt eraan

Hah! Deze opmerking ben ik dus zo'n 10x tegengekomen in heel het topic - al vanaf april of mei ofzo.

Als je er hulp bij nodig hebt, dan hoef je maar te gillen hoor.

btw: ik zal zo effe wat andere posts hiervoor toelichten - ben nu druk bezig op de zaak.

[drm]

Explore schreef op 14 oktober 2002 @ 16:38:
Hah! Deze opmerking ben ik dus zo'n 10x tegengekomen in heel het topic - al vanaf april of mei ofzo.

hmpf. Zoek het dan zelf maar uit hoor

Als je er hulp bij nodig hebt, dan hoef je maar te gillen hoor.

nodig, nodig, da's zo'n groot woord

^</offtopic>

[Explore]

killercow schreef op 14 oktober 2002 @ 11:05:
[...]


iid daar was ik al achter maar ik kom voor geen meter verder
de rest schiet al aardig op maar zonder alle tiles kan ik niet beginnen met het genereren van maps, zelfs nemesis (world generator) draait al aardig alleen kan ik nu nog steeds alle tiles met de hand gaan lopen fizen en dat zuigt.

zou jij met hands-on willen helpen? via msn / ftp oid?
dan kan ik namenlijk die techniek uitbreiden en eventueel klaar maken voor gebruik in snowstorm.

fizen?

Gebruiken voor snowstorm zou wel cool zijn, imho.
msn doe ik niet aan. icq evt. wel.

Even vraagje: ik neem aan dat je tiles redelijk predefined zijn en dat je geen compleet willekeurige hoeken kan hebben in je map - aangezien het dhtml is en geen complete 3d engine in C of Asm. Als dat zo is kan je een aantal aardige optimalisaties invoeren en hoef je je amper druk te maken over hoeken in 3d uitrekenen.

Btw: Ik ben nu weer op de zaak aan de gang. Gisterenavond naar concertgebouw geweest dus geen tijd gehad... vanavond wellicht weer...

[Verwijderd]

heb ook iets gemaakt.. vrij ranzige code..
is een selectiedemo.. weet niet of dat gebruikt moet gaan worden.. misschien handig voor als je een weg wilt tekenen ofzo..
http://www.countertrack.com/sel/

[killercow]

tjabber, coole zooi man die is echt wel handig idd. ook voor hekken en dergeleiken

explore: de tiles moeten door een tilegenerator van te voren gemaakt worden, deze tile gen kan nu al de omtrek ed maken en deze invullen met een bepaalde texture maar ik krijg het dus niet voor elkaar om ook de gamma goed te krijgen.
ik moet dus de 3e berekening nog doen, en dan omzetten naar een waarde zodat ik het aan de gamma correctie tool van php kan voeren. hierna kan ik natuurlijk alle mogenlijke tiles genereren en opslaan zodat de game veel lichter wordt.

[LuCarD]

Verwijderd schreef op 15 oktober 2002 @ 11:36:
heb ook iets gemaakt.. vrij ranzige code..
is een selectiedemo.. weet niet of dat gebruikt moet gaan worden.. misschien handig voor als je een weg wilt tekenen ofzo..
http://www.countertrack.com/sel/

push wordt niet ondersteunt door IE5.0

Onderstaande ervoor plakken en dat werkt hij goed...

code:

if(!Array.prototype.toSource) {
    function array_tosource(){
        st = "";
        for(var i=0;i<this.length;i++) {
            tEl = this[i];
            switch(typeof tEl){
                case "string":
                    st+="\"" + tEl.replace(/"/g,"\\\"") + "\"";
                    break;
                case "object":
                    st+=tEl.toSource();
                    break;          
                default:
                    st+=tEl
            }
            if(i<this.length-1)st+=","
        }
        return "[" + st + "]"
    }
    Array.prototype.toSource = array_tosource;
}

if(!Array.prototype.shift) {
    function array_shift() {
        firstElement = this[0];
        this.reverse();
        this.length = Math.max(this.length-1,0);
        this.reverse();
        return firstElement;
    }

    Array.prototype.shift = array_shift;
}

if(!Array.prototype.unshift) {
    function array_unshift() {
        this.reverse();
        for(var i=arguments.length-1;i>=0;i--){
            this[this.length]=arguments[i]
        }
        this.reverse();
        return this.length
    }
    Array.prototype.unshift = array_unshift;
}

if(Array.prototype.push && ([0].push(true)==true))Array.prototype.push = null;
if(Array.prototype.splice && typeof([0].splice(0))=="number")Array.prototype.splice = null;

if(!Array.prototype.push) {

    function array_push() {
        for(i=0;i<arguments.length;i++){
            this[this.length]=arguments[i]
        };
        return this.length;
    }
    Array.prototype.push = array_push;

}

if(!Array.prototype.pop) {

    function array_pop(){
        lastElement = this[this.length-1];
        this.length = Math.max(this.length-1,0);
        return lastElement;
    }

    Array.prototype.pop = array_pop;

}

if(!Array.prototype.splice) {

    function array_splice(ind){
        if(ind==null) return ind;
        if(ind<0) ind = this.length + ind;
        if(ind > this.length) {
            if(arguments.length>2) ind = this.length;
            else return [];
        }
        cnt = arguments[1] ? arguments[1] : this.length-ind;

        firstArray = [];
        secondArray = [];
        thirdArray = [];

        for(var i=0;i<this.length;i++){
            tEl = this[i];
            if(i<ind) firstArray.push(tEl);
            else if(i<ind+cnt) secondArray.push(tEl);
            else thirdArray.push(tEl);
        }

        this.length = firstArray.length;
        for(i=2;i<arguments.length;i++){
            this.push(arguments[i]);
        }
        this.concat(thirdArray);
        return secondArray;
    }

    Array.prototype.splice = array_splice;

}

[David]

Het lijkt me alleen erg ambitieus en niet erg noodzakelijk om hekken of muren in het spel zelf te bouwen.

Een level editor is natuurlijk wel cool (we blijven in de stijl van Blizzard )

[killercow]

mischien geen hekken ed in snowstorm maar ik kan t goed gebruiken, m'n eigen game is namenlijk ook isometrisch

[Clay]

Qua tile collision dacht ik aan tiles van 128 * 64 (rechthoekig de box zeg maar) die je als unit wel of niet kan betreden. Evt om hoogte levels te simuleren kan je een tile een hoogte-ID geven, aangrenzende tiles met hetzelfde hoogte-ID kan je wel naartoe lopen, lagere of hogere niet, tenzij je er via "het pad" op of af loopt.

De meest ideale situatie voor levels maken zou een "editor" zijn, waar je een bepaald tiepe grondsoort aanklikt, en die op je level brusht. Dat principe is al eerder gepost, het enige wat het nog mooier maakt is de overgangen van type naar type aan de rand tiles met images te regelen. dus gras naar modder in enkele verschillende hoek overgangen. enz.

[Verwijderd]

ben net bezig geweest om een weg te tekenen.. is nog best wel lastig..
op http://www.countertrack.com/sel/index2.html kan je 't al een beetje zien.. probleem is alleen dat je heel erg veel verschillendetiles moet maken en je per geplaatste tile moet checken.. zitten nog een hoop fouten in, maar 't idee is aardig..
(javascript error als je dichter dan 1 van de rand af komt.. dit moet er uiteraard nog uit )

weet iemand 't algoritme dat ze bij simcity 2000 hebben gebruikt voor wegen?

[Verwijderd]

op http://www.gamedev.net/reference/list.asp?categoryid=44 kan je veel vinden over tilebased games..
en op http://www.gamedev.net/reference/articles/article934.asp staat een tutorial over die transitions..

[David]

Cool! Een level editor

Ik ben er trouwens wel voor om PHP of ASP te gaan gebruiken. Daarmee kunnen we makkelijk multiplayer-modes implementeren, de gamers een mogelijkheid geven om hun games te saven etc. De game zelf draait dan uiteraard gewoon op DHTML, en in het geval van saven of laden roepen we gewoon een extern PHP-script aan.

offtopic:
Tjabber, even een bythewaytje: www.countertrack.com werkt niet in Mozilla

[Verwijderd]

Dat countertrack.com niet werkt in mozilla wete ik.. hij werkt geloof ik alleen maar in internet explorer.. maar dat boeit niet..
't is meer een plaats waar ik dhtmlspullen neerzet.. en omdat ik geen zin heb om weet ik veel hoeveelchecks enzo erbij te maken en er vml gebruikt wordt werkt alles ongeveer alleen maar in internet explorer.

[Explore]

Clay schreef op 14 oktober 2002 @ 09:32:
Ik leef in de veronderstelling dat alle graphics zelf gefabriceerd gaan worden, nix "geleend" van bestaande games dus

Lijkt me wel zo raadzaam. Anders wordt het geheel gelijk als rip-off gezien.

Die selectie demo is erg cool

Thanks

En wat mozilla betreft is dat niet zo erg, want omdat het imo extreem belangrijk is dat alles modulair en transparant wordt opgezet komt er een grafische onderlaag die alle browserspecifieke dhtml dingen overneemt. een layer (sprite) beweeg je dus niet met ding.style.left.... maar met sprite.moveTo(), die moveTo zorgt dan wel dat het overal in werkt.
Idem voor events; Omdat er waarschijnlijk een oerwoud aan mouse (en andere) event handlers moet komen kan je niet met document.onmousemove = .... iets aan de muis gaan koppelen wanneer je dat nodig hebt, dat zou immers alle vorige mousemove handlers overschrijven. Dat zal dan met iets ala document.attachEvent("eventtype", referentie); gaan. Dit (het is niet de IE attachEvent, maar een gescripte) voegt die referentie TOE aan de bestaande lijst van eventhandlers die op dat tiepe moet reageren, en voert ze dus allemaal uit, zodat je eindeloze handlers op 1 event kan zetten (ook "onload").

Precies wat ik dacht... Nee echt...

Het enige wat ik wel zou veranderen aan die selectie is hem niet ondrag de selectie laten zoeken, maar onmouseup, puur voor de "optimalisatie".

Zou kunnen. Ik ga tzt nog wel eens pielen met de code. Ben nog niet helemaal content. Als het niet te optimalizeren valt dan wordt dat inderdaad het alternatief.

Fog of war is in principe natuurlijk ook belangrijk dat zou je kunnen doen door de tiles die je nog niet gezien heb gewoon zwart te maken (nog een laag eroverheen leggen is denk ik overkill) en alles wat daar aan layers in zit op hidden te zetten, of je kan het gewoon zo doen dat je als speler je view niet verder dan een dX en dY van je eigen units vandaaan mag doen.

Dus voeg maar toe aan de tile-spec: een item 'isSeen' welke default FALSE is.

Ik dacht inderdaad dat het puur single player ging worden, en wat de computer betreft, die moet in principe 100% Object based/oriented worden zodat het technisch niet uit maakt of je als speler nou 1 of 10 computers tegen je hebt. In je code definieer je het prototype, het aantal instanties moet vrij zijn.

Inderdaad, met een aantal startup parameters, zoals start locatie op de map en 'intelligentie', etc...

Wat betreft het aantal plaatjes wat nodig is voor bv. een tank hoor ik telkens andere getallen. Toch nog eens even nagaan, hoor:

4 voor N, O, Z, W
4 voor NO, ZO, ZW, NW

Dat zijn er dus 8 verschillende plaatjes in totaal. Maar die zijn dan staties. Ik kan me voorstellen dat er een 'animatie' van 2 plaatjes in elke unit zit. Dit zou dan (inderdaad) resulteren in 16 verschillende plaatjes per unit.

Echter... dan ben je d'r nog niet. Ik kan me voorstellen dat bij bv. tanks de turret (de loop van 't kanon, zeg maar) los van het voertuig kan bewegen. Lijkt me handig om dat in een aparte layer te zetten, als dat tenminste nodig is. Maarja, anders zou een tank eerst moeten draaien alvorens deze een bepaalde kant op kan schieten, als je de zaak tenminste echt wil laten kloppen...

En wat betreft het isometrisch perspectief. Ik vraag me af of dat nodig is. Misschien een stomme vraag, maar kunnen we de kaart niet gewoon in een normaal grid laten lopen (dus horizontaal en vertikaal ipv. diagonaal) en alle plaatjes van gebouwen, tanks, mannetjes, ed. allemaal onder een hoek tekenen? Krijg je dan netto niet hetzelfde effect, maar veel simpeler programmeerbaar?

Woudloper:
Verder maak je een goed punt met betrekking tot dit posting van Apollo_Futurea. Het is ook nog zo dat dit geheel nog steeds openstaat en zo, want we gaan pas écht verder als Beehive(2)...

Die post refereert puur naar het algoritme met betrekking tot laten rijden/lopen van de units. Niet zozeer het verplaatsen van layers. Er zitten nogal wat haakjes en ogen aan het implementeren van zo'n algoritme. Stel je het volgende voor:

code:

+---+---+
| x | A |
+---+---+
|   | y |
+---+---+

'x' en 'y' zijn twee tanks die allebei naar tile 'A' willen. Het algoritme wat Apollo_Futurea voorsteld (hoe goed het ook in elkaar steekt) gaat hier falen: voor allebei de tanks is tile A in eerste instantie vrij en ze zullen dus allebei tegelijk naar tile A gaan... Dat mag dus niet. Dit is nog maar 1 voorbeeld...

Wat betreft het overzichtskaartje:

Dit klinkt wel grappig en ik heb hier ook mee lopen spelen, maar is het niet zo dat dit ook voor meer performance zorgt Persoonlijk zie ik dit als een feature (mogelijke toekomstige toevoegingen...) en heeft het (in mijn ogen) nog geen prioriteit, maar wellicht dat andere hier anders over denken...

Op zich valt het wel mee. Voor het overzichtskaartje gelden ongeveer dezelfde regels als voor de speelkaart: wat op de grote kaart 'unexplored' is, is niet zichtbaar op de overzichtskaart en units die zich in zo'n 'unexplored territory' bevinden zijn hidden. Verder is alles op de overzichtskaart op een schaal van 1 pixel - bijvoorbeeld. Dus echt heavy is het niet. Ik kan me voorstellen dat het een optioneel item is voor mensen die een beetje een heavy systeem hebben, in het geval dat het toch veel performance kost.

Ik heb hier overigens ook mee lopen spelen, maar dan in een andere mate...

Zo, verder werken...

[Clay]

Als de levels pre-defined zijn (dus niet random) kunnen we gewoon jpg'tjes op schaal bakken die de map vertegenwoordigen, en dan iig de gebouwen daarop aangeven. units -misschien- ook, maar dat lijkt mij lagere prio hebben ivm de system load van alle andere zaken die gaan draaien tijdens het spel.

En wat betreft het isometrisch perspectief. Ik vraag me af of dat nodig is. Misschien een stomme vraag, maar kunnen we de kaart niet gewoon in een normaal grid laten lopen (dus horizontaal en vertikaal ipv. diagonaal) en alle plaatjes van gebouwen, tanks, mannetjes, ed. allemaal onder een hoek tekenen? Krijg je dan netto niet hetzelfde effect, maar veel simpeler programmeerbaar?

Misschien idd wel, maar hoe laat je stukken landschap dan in elkaar overlopen? met vierkanten kan je het isometrische perspectief denk ik maar met moeite nadoen, met rechthoeken misschien nog wel, en op zich wordt het coordinaten stelsel toch gewoon horizontaal en vertikaal, er hoeft alleen maar op basis van die gewone x en y een tile object aangeroepen te kunnen worden, als dat 1 keer staat (en daar wou ik morgen of van het weekend eindelijk eens wat mee doen ) heb je geen omkijken meer naar de isometrie.

Echter... dan ben je d'r nog niet. Ik kan me voorstellen dat bij bv. tanks de turret (de loop van 't kanon, zeg maar) los van het voertuig kan bewegen. Lijkt me handig om dat in een aparte layer te zetten, als dat tenminste nodig is. Maarja, anders zou een tank eerst moeten draaien alvorens deze een bepaalde kant op kan schieten, als je de zaak tenminste echt wil laten kloppen...

yup. Denk ik ook. en een tank -moet- eigenlijk wel een losse turret hebben

[David]

Zozo, da's klare taal.

Afstappen van een isometrisch raster kan natuurlijk (nu ik even nadenk: Starcraft gebruikt ook geen isometrisch raster) en dan hebben we geen omrekenalgoritme nodig.

code:

:
+---+---+
| x | A |
+---+---+
|   | y |
+---+---+

'x' en 'y' zijn twee tanks die allebei naar tile 'A' willen. Het algoritme wat Apollo_Futurea voorsteld (hoe goed het ook in elkaar steekt) gaat hier falen: voor allebei de tanks is tile A in eerste instantie vrij en ze zullen dus allebei tegelijk naar tile A gaan... Dat mag dus niet. Dit is nog maar 1 voorbeeld...

Ik neem aan dat we units niet naar een specifieke tile laten bewegen maar gewoon naar een X,Y-coordinaat (tenzij je de minimap gebruikt). Als we elke unit een soort van 'lebensraum' meegeven (een ruimte om ze heen die ze innemen) en andere grote units daar niet binnen mogen komen. Kleinere units mogen gewoon doorlopen totdat ze tegen de daadwerkelijke unit aanlopen (denk in Starcraft aan Zerglings die een Siege-Tank aanvallen) om niet al te vreemde grafische onvolkomendheden te krijgen. Check gewoon tijdens het moven via een collision-detection algoritme (moeten we sowieso hebben) of ze daar wel mogen komen.

Het komt er dan dus neer dat je zoveel units naar een punt mag bewegen als je wilt, maar dat de units via collision-detection uitmaken dat ze niet op/onder elkaar terecht komen.

[Clay]

* Update *

nieuwe map demo
De maptest die ik een tijd geleden had gemaakt is geupdate en samengevoegd met de unittest, samen met verschillende andere hier geposte ideeen, tests en demo's, en dat is nu dit geworden: woei!

• 1 van de units aanklikken deselecteert de andere _niet_
  Selectie trekken met muis om 1tje _wel_
• Een geselecteerde unit kan alleen naar 1 van de 4 ernaast liggende velden lopen, enz. niet zomaar 2 of 10 in 1 keer. Dit is om in de code een mini voorbeeld van buur-tiles te hebben. Het transparante deel kan je op deze manier (wel door snel "een circel pad eromheen" te klikken) niet op.
  Elke tile kent zijn (4) buren, op zich kan dus al gepoogd worden hier een path algoritme voor te maken.
• Een unit legt nog steeds zijn afstand in 1 seconde af, hoe ver weg die ook moet. Eigenlijk moet een unit gewoon een speed hebben, en met die speed naar een tile kunnen lopen, waarna die (path) doorgaat naar de volgende. morgen weer een dag
• Code zit dan wel vol met commentaar, ik heb zelf ook altijd moeite om snel code van anderen te doorgronden, dus hoewel ik denk dat het redelijk overzichtelijk gescript is zal ik echt wel nodig docs en diagrammen moeten gaan maken
• Veel dingen in de code zijn nog suf, onlogisch, slordig, of moeten gewoon anders.

[Ericston]

Uhm... koel.

[Verwijderd]

Clay schreef op 18 oktober 2002 @ 22:32:• Een geselecteerde unit kan alleen naar 1 van de 4 ernaast liggende velden lopen, enz. niet zomaar 2 of 10 in 1 keer. Dit is om in de code een mini voorbeeld van buur-tiles te hebben. Het transparante deel kan je op deze manier (wel door snel "een circel pad eromheen" te klikken) niet op.

eehm dat kan wel hoor

ik kan dus wel gewoon over dat transparante gedeelte heenwandelen als ik een beete snel doorklik

[Clay]

Wat kan wel hoor

[Ericston]

Verwijderd schreef op 19 oktober 2002 @ 11:14:
[...]
eehm dat kan wel hoor
[...]

Je moet iets beter lezen.

[Verwijderd]

edit:

dit heeft dus betrekking op mijzelf, ik had dus de post van clay niet goed gelezen, want hij gaf juist al aan dat dat mogelijk was

[ Voor 0% gewijzigd door Verwijderd op 19-10-2002 17:34 . Reden: uitleg ]

[Verwijderd]

Verwijderd schreef op 19 oktober 2002 @ 17:15:

-1000 overbodig. Clay hij bedoelt dat hij wel over het transparante gedeelte heen kan wandelen.

[Explore]

Clay schreef op 18 oktober 2002 @ 22:32:
* Update *

nieuwe map demo
De maptest die ik een tijd geleden had gemaakt is geupdate en samengevoegd met de unittest, samen met verschillende andere hier geposte ideeen, tests en demo's, en dat is nu dit geworden: woei!

Cool!

[gvdh81]

Ok voor de mensen die geen zin hebben om 10 pagina's te gaan lezen;
Wat wordt er gemaakt, en hoe ver zijn we dermee?

[HawVer]

Clay schreef op 18 oktober 2002 @ 22:32:
* Update *

nieuwe map demo
De maptest die ik een tijd geleden had gemaakt is geupdate en samengevoegd met de unittest, samen met verschillende andere hier geposte ideeen, tests en demo's, en dat is nu dit geworden: woei!

• 1 van de units aanklikken deselecteert de andere _niet_
  Selectie trekken met muis om 1tje _wel_
• Een geselecteerde unit kan alleen naar 1 van de 4 ernaast liggende velden lopen, enz. niet zomaar 2 of 10 in 1 keer. Dit is om in de code een mini voorbeeld van buur-tiles te hebben. Het transparante deel kan je op deze manier (wel door snel "een circel pad eromheen" te klikken) niet op.
  Elke tile kent zijn (4) buren, op zich kan dus al gepoogd worden hier een path algoritme voor te maken.
• Een unit legt nog steeds zijn afstand in 1 seconde af, hoe ver weg die ook moet. Eigenlijk moet een unit gewoon een speed hebben, en met die speed naar een tile kunnen lopen, waarna die (path) doorgaat naar de volgende. morgen weer een dag
• Code zit dan wel vol met commentaar, ik heb zelf ook altijd moeite om snel code van anderen te doorgronden, dus hoewel ik denk dat het redelijk overzichtelijk gescript is zal ik echt wel nodig docs en diagrammen moeten gaan maken
• Veel dingen in de code zijn nog suf, onlogisch, slordig, of moeten gewoon anders.

Extra toevoeging

Ik kan ook niet meer door de map heen scrollen. En dat klopt?
En het selecteren van zo'n tile komt geeft een lijntje erom heen. Blijft dat zo?
Wat je ook als nadeel hebt dat als je de één niet kan deselecteren en beide units over elkaar heen gaan dat je ze niet meer van elkaar kan krijgen. Maar daar had je vast al rekening mee gehouden.
Goed bezig. Leuk dat hij al je stappen onthoud waar je op klikt. Dan moet je sneller zijn als 1 seconde.

[Woudloper]

Clay, het ziet er erg goed uit Gelukkig heb ik mij al eens verdiept in de manier waarop jou spelletjes e.d. in elkaar zitten, want dan leest het toch een stuk gemakkelijker. Voor de nieuwe(re) mensen is het wellicht handig dat er tóch een soortement van documentatie komt*

Leuk gedaan overigens om die selectiekaders van de units/map e.d. gewoon uit afbeeldingen te laten bestaan. Ik zat eerst te denken aan een leuke/gave CSS oplossing, maar dat bleek niet zo te zijn...

Het is trouwens wel zo dat de unit gewoon over het transparante vlak heenschuift (mits je natuurlijk snel genoeg aan het klikken bent). Wellicht dat degene die eerder in dit topic hun pathfinder algoritme hebben bedacht deze kunnen uitwerken (ofwel een werkend voorbeeld geven) zodat het één en ander geïmplementeerd kan worden en de unit gewoon zijn weg kan vinden. Zelf ben ik daar namelijk minder sterk in hoewel ik altijd uitmuntende cijfers had voor wiskunde. (Ik zie het waarschijnlijk nog niet...)

Het tekenen van zo'n map ziet er erg eenvoudig uit, maar even voor mijn perceptie. Wanneer er in een toekomstige situatie een map komt (* Woudloper neemt aan dat dit gewoon een grote .jpg is) is het dan zo dat deze:

1. Als het ware achter de map ligt
2. Je met behulp van de nummertjes (1,2,3,4) je de map opbouwt
   code:
   

   +----+
   |    |
   |    +-------+
   |            |
   |            |
   |    +-+     |
   |    | |     |
   |    +-+   +-+
   |          |
   |          |
   +----------+

   Ik vraag mij dan af hoe je een map als bovenstaande zal tekenen

Verder ziet het er erg goed uit Had je er niet een (binnen het transparante gedeelte) ervoor kunnen zorgen dat het geen selectie kadertje toonde?

offtopic:
* Dit moet je toch ook nog doen voor Beehive Met andere woorden: je hebt er dubbel zoveel plezier van

[Clay]

De map wordt juist geen grote jpg, maar wordt opgebouwd uit allemaal losse tile images. Dat maakt het ook mogelijk om sneller meer verschillende levels te maken (wat niet bepaald makkelijk is als voor elke map een nieuwe grote jpg gemaakt moet worden) De 1, 2, 3 enz. geven dan het type tile aan, waarbij het de bedoeling is dat het script zelf de goede tile van dat type plaatst om alle tiles netjes in elkaar over te laten lopen.

Dat je als je snel klikt wel over het transparante deel kan had ik meteen al gezegd, maar dat schijnt niemand te lezen

HawVer schreef

Extra toevoeging
Nou niet echt nee. Maar losse demo's is 1 ding, alles samenvoegen in 1 werkend geheel is weer heel wat anders.

Ik kan ook niet meer door de map heen scrollen. En dat klopt?
Ja. maar de constructie die dat mogelijk maakt is er nog wel. Het scrollde eerst "real time" met de muis mee. Dat lijkt me ivm performance in de final niet echt handig.

En het selecteren van zo'n tile komt geeft een lijntje erom heen. Blijft dat zo?
Nee, wat mij betreft niet. Dit is puur ter indicatie.

Wat je ook als nadeel hebt dat als je de één niet kan deselecteren en beide units over elkaar heen gaan dat je ze niet meer van elkaar kan krijgen. Maar daar had je vast al rekening mee gehouden.
Path & collision zit er (nog) niet in nee, op zich mogen units natuurlijk eigenlijk niet over elkaar heen liggen.

[crisp]

Hoe werkt dat eigenlijk in zo'n spel; doen spelers om beurten units verplaatsen, of kunnen meerdere units onafhankelijk van elkaar gelijktijdig verplaatst worden.
In het 1e geval is path-finding aanzienlijk makkelijker omdat je op dat moment van een statische situatie uit kan gaan; in het tweede geval moet je al lopend elke keer je gevonden pad gaan verifieren om te kijken of er door een andere beweging geen obstakels in de weg zijn komen staan...

[Woudloper]

Clay:
De map wordt juist geen grote jpg, maar wordt opgebouwd uit allemaal losse tile images. Dat maakt het ook mogelijk om sneller meer verschillende levels te maken (wat niet bepaald makkelijk is als voor elke map een nieuwe grote jpg gemaakt moet worden) De 1, 2, 3 enz. geven dan het type tile aan, waarbij het de bedoeling is dat het script zelf de goede tile van dat type plaatst om alle tiles netjes in elkaar over te laten lopen.

Ja, dat is natuurlijk stom dat ik dat zeg... Was nog niet helemaal wakker en nee had jou stukje dus ook niet goed (mbt transparantie) niet goed gelezen

Nog ff terugkomen op die type tiles. Was het nou ook mogelijk om daar specifieke eigenschappen aan mee te geven. Ja, toch

edit:
Op de 'verstuur bericht' knop gedrukt ipv 'bekijk bericht'.. Natuurlijk is het zo dat je specifieke eigenschappen kan meegeven, zie het voorbeeld maar...

Nog maar ff een bakkie doen

[Clay]

crisp schreef op 22 oktober 2002 @ 09:28:
Hoe werkt dat eigenlijk in zo'n spel; doen spelers om beurten units verplaatsen, of kunnen meerdere units onafhankelijk van elkaar gelijktijdig verplaatst worden.
In het 1e geval is path-finding aanzienlijk makkelijker omdat je op dat moment van een statische situatie uit kan gaan; in het tweede geval moet je al lopend elke keer je gevonden pad gaan verifieren om te kijken of er door een andere beweging geen obstakels in de weg zijn komen staan...

iedereen mag alles tegelijk doen. Maar je zou het pathfinden ook zo kunnen doen dat ie wel een globaal pad heeft over een aantal tiles, maar dat de unit binnen zo'n tile nog ff kijkt of die niet tegen andere units gaat opbotsen. Een tile blokken omdat er teveel units op staan is dan misschien ook niet zo'n goed idee, dat maakt het alleen maar ingewikkelder.

[David]

Wat vinden jullie trouwens van het idee om rechthoekige tiles te gebruiken ipv. ruitvormige?

Even een zelfquote

Afstappen van een isometrisch raster kan natuurlijk (nu ik even nadenk: Starcraft gebruikt ook geen isometrisch raster) en dan hebben we geen omrekenalgoritme nodig.

We renderen/pixelfucken dan alle plaatjes wel isometrisch. Ik zie namelijk het nut niet van het sturen van een unit naar een tile. We kunnen units veel beter naar een X,Y-coordinaat sturen. Da's veel makkelijker te proggen, werkt een stuk sneller en is exacter. Colission-detection zal wel omgegooid moeten worden, maar je hoeft niet meer te checken of er al een unit op die tile aanwezig is.

Ik hoop dat jullie mijn idee een beetje volgen. Volgens mij is dit gewoon veel beter.

[crisp]

Clay schreef op 22 oktober 2002 @ 10:09:
[...]


iedereen mag alles tegelijk doen. Maar je zou het pathfinden ook zo kunnen doen dat ie wel een globaal pad heeft over een aantal tiles, maar dat de unit binnen zo'n tile nog ff kijkt of die niet tegen andere units gaat opbotsen. Een tile blokken omdat er teveel units op staan is dan misschien ook niet zo'n goed idee, dat maakt het alleen maar ingewikkelder.

Oftewel je stopt als er zich onverhoopt toch een unit zich op jouw eerstberekende pad bevind? Path-finding in-time is natuurlijk een stukje zwaarder omdat je elke stap je path moet verifieren, en als er iets onverhoopt in de weg staat een nieuw path moet gaan uitrekenen; het kan allemaal wel natuurlijk, maar kost wat rekenkracht....

[David]

crisp schreef op 22 oktober 2002 @ 22:28:
[...]

Oftewel je stopt als er zich onverhoopt toch een unit zich op jouw eerstberekende pad bevind? Path-finding in-time is natuurlijk een stukje zwaarder omdat je elke stap je path moet verifieren, en als er iets onverhoopt in de weg staat een nieuw path moet gaan uitrekenen; het kan allemaal wel natuurlijk, maar kost wat rekenkracht....

Deze discussie is al eerder in het topic gevoerd: je hoeft niet constant alle units te laten colission-detecten of pathfinden. Je laat een unit een pad uitstippelen. Check in het begin of er units in de buurt zijn. Zijn ze ver weg, dan kun je met een lekker grote tijdsinterval colission-detecten. Staat de unit vlakbij een andere unit, dan wordt de tijdsinterval kleiner. Pas als de units echt botsen hoeft het pad veranderd te worden.

Het zou namelijk onzin zijn dat als een unit een pad uitkiest, en er tijdens zijn tocht over dat pad er een andere unit heel ergens anders op zijn pad het pad kruist (<- sorry, 't kon niet duidelijker) hij een nieuw pad moet gaan finden.

[Clay]

DiMension schreef op 22 oktober 2002 @ 22:05:
Wat vinden jullie trouwens van het idee om rechthoekige tiles te gebruiken ipv. ruitvormige?

We renderen/pixelfucken dan alle plaatjes wel isometrisch. Ik zie namelijk het nut niet van het sturen van een unit naar een tile. We kunnen units veel beter naar een X,Y-coordinaat sturen. Da's veel makkelijker te proggen, werkt een stuk sneller en is exacter. Colission-detection zal wel omgegooid moeten worden, maar je hoeft niet meer te checken of er al een unit op die tile aanwezig is.

Ik hoop dat jullie mijn idee een beetje volgen. Volgens mij is dit gewoon veel beter.

Prima, maar ik zie niet hoe je met rechthoeken tileable ruit-based tiles kan renderen? Kan je dat anders misschien even verduidelijken in een plaatje? Verder stuurt wat ik laatst postte een unit niet direct naar een tile, maar gewoon naar een normale x / y coordinaat. Obv die coordinaat wordt de tile opgezocht, en als object teruggegeven. De unit heeft dan op zijn beurt die "moveToTile" functie, maar dat kan natuurlijk ook anders. Als units werkelijk met elkaar gaan colliden staat er niets in de weg dat met normale x'en en y'en te doen. Sterker nog, dat is de bedoeling! het is onnodig ingewikkeld, overkill, en suf om alles in een zelf-gefabriceerd diagonaal x/y stelsen te proggen.
Feit blijft ook dat je _altijd_ uit zal gaat van een rechthoekig systeem, of een vertaling daarnaartoe. Ook dit wat er nu staat is gewoon een vertaling van ruit naar rechthoek. Html is per definitie rechthoekig (doh), dus een systeem zonder ruit-tiles zoals die nu zijn zal in wezen gewoon een andere vorm zijn om isometrisch perspectief naar een rechthoekig html systeem te vertalen

[Woudloper]

Clay, soortement van conclusie dan over jouw stukje Jij wil eigenlijk zeggen dat het niet uitmaakt (qua perfomance e.d.) of er wordt gewerkt met een rechthoek of ruitvorm omdat je toch de vertaling moet doen...

[Clay]

qua performance weet ik niet dat zou natuurlijk best kunnen verschillen per oplossing, maar die vertaling van rechthoekig naar tile moet je idd volgens mij wel blijven doen ja, hoe je het ook aanpakt.

[David]

Clay schreef op 23 oktober 2002 @ 13:55:
qua performance weet ik niet dat zou natuurlijk best kunnen verschillen per oplossing, maar die vertaling van rechthoekig naar tile moet je idd volgens mij wel blijven doen ja, hoe je het ook aanpakt.

Vertaling van rechthoek naar tile is heel simpel. Je hoeft per X,Y-coordinaat maar 2 simpele delingen te doen.


Even verduidelijkend plaatje van een paar posts terug:


Je ziet dat Starcraft rechthoekige tiles gebruikt. Het plaatje van de supply depot is gewoon isometrisch gerenderd/getekend.

[Clay]

Volgens mij praten we langs elkaar heen ik bedoel het landschap. niet de units/buildings.

[edit]

uit de editor (lelijke ding is de "brush" waar je meer verft):

[David]

Clay schreef op 23 oktober 2002 @ 19:56:
Volgens mij praten we langs elkaar heen ik bedoel het landschap. niet de units/buildings.

[edit]

uit de editor (lelijke ding is de "brush" waar je meer verft):
[afbeelding]

Achso. We moeten sowieso een heel stel verschillende landschap-tiles maken.
We kunnen het beste toch gewoon rechthoekige tiles maken met isometrisch landschap daarop. Op http://www.gamedev.net/reference/articles/article934.asp kun je het een en ander over overgangen vinden tussen soorten landschap. In de Starcraft-editor is het waarschijnlijk ook gewoon een fancy-isometrisch vakje om een rechthoekige brush heen. Je werkt toch met vantevoren gedefinieerde plaatjes.

[Clay]

We kunnen het beste toch gewoon rechthoekige tiles maken met isometrisch landschap daarop.

Maar waarom dan en vooral hoe?
Wat ik probeer te vragen is dit:



Hoe ga je met rechthoeken ipv van ruiten bijvoorbeeld dit "gras" zo om de hoek laten lopen. Als je zoiets doet als hieronder (rechthoek in't wit):



heb je voor 1 tile in de "oude" situatie al 4 tiles nodig, die moeten allemaal in hun eigen tablecell, en het aantal daarvan is ook beperkt. Ook het aantal images per tilesoort neemt toe. In ruitvorm heeft het bovenstaande voorbeeld er 4. een volle, een "op" en "neer", en een hoekstuk. op de onderstaande manier zouden er 7 nodig zijn. 2 voor op, 2 voor neer, 2 voor het hoekstuk, en een volle.
Ik zie dus nog niet wat het voordeel is van rechthoeken ipv ruiten.

Leg anders ff uit wat je precies bedoelt?

[David]

Je maakt bij het bouwen gebruik van twee lagen rechthoekige tiles. De tiles zijn per laag ten opzichte van elkaar een halve tilehoogte en een halve tilelengte verschoven. Het werkt dus inderdaad anders dan bij de gewone units en gebouwen. Zulke kleine rechthoekige tiles gebruiken zoals jij schetst is inderdaad omslachtig.

Ik denk dat wat wij bedoelen op hetzelfde neerkomt..

[killercow]

weleens over nagedacht om mischien alleen borders te tekenen?
deze borders kun je dan in een laag over de normale achtergronden plaatsen, je kunt dan ook gelijk weinig tiles (geen border layer) gebruiken voor lichte machines en mooie maps met border tiles voor de zware machines.

je moet dus alleen de overgangen tekenen in dunne strookjes, daarna draai je die strookjes naar de juiste positie en plak je ze bovenop de normale tiles, voila je hebt een mooi aflopen stukje gras/water/berg/asfalt.

doordat je in de versie zonder mooie randjes veel minder images nodig hebt wordt deze dus ook enorm veel makkelijker voor de lichtere machine.,

enventueel kun je nog gaan klooien met doorzichtige rotzooi tiles bovenop al die lagen welke bijvoorbeeld kraters/guelen/afwijkingen in de normale ondergrond/borders aanbrengt, maar ook hier, instelbaar detail?

[Explore]

Clay schreef op 23 oktober 2002 @ 22:18:

...

heb je voor 1 tile in de "oude" situatie al 4 tiles nodig, die moeten allemaal in hun eigen tablecell, en het aantal daarvan is ook beperkt. Ook het aantal images per tilesoort neemt toe. In ruitvorm heeft het bovenstaande voorbeeld er 4. een volle, een "op" en "neer", en een hoekstuk. op de onderstaande manier zouden er 7 nodig zijn. 2 voor op, 2 voor neer, 2 voor het hoekstuk, en een volle.
Ik zie dus nog niet wat het voordeel is van rechthoeken ipv ruiten.

Leg anders ff uit wat je precies bedoelt?

Goeiemorgen... Zullen we maar gewoon ruitvormige tiles nemen, zoals je al een tijdje gebruikt in de voorbeelden? Volgens mij werkt dat prima en je hebt het omreken-gebeuren toch al uitgedacht...

Dat idee van transparante tiles, die over andere tiles heengelegd kunnen worden is misschien wel leuk. Ik weet niet of het nodig is, echter. Ik zou 't gewoon simpel en straight-forward houden.

Gewoon ruitvormige tiles in rechthoekig raster, dus 2 lagen en niet meer. Geen gepiel, geen gedoe.

Zo, we kunnen weer verder.

werkuh...

[David]

Even een verpakte schop

We gaan voor drie rassen:
-De mensen (nee, ok deze ontbreken weer eens niet)
-Een volk dat in harmonie leeft met de natuur, maar geen elf is (hoor ik night-elf? )
-Robots

Zo, ga maar ruziën

[Clay]

Ik ben het ermee eens.

Naja bijna dan. Ik denk wel dat het wat moeilijk is om voor tree huggin' hippies (elfjes, red.) units te verzinnen die realistisch vergelijkbaar zijn met siegetanks, battedroids en cruisers. Houten constructies die ook maar 1 schot van zulk soort wapentuig overleven komen misschien wat onrealistisch over Alhoewel datzeflde eigelijk ook geldt voor de zerg, en daar heb ik me tot nu (ja nu) toe ook nooit vragen bij gesteld.

[David]

Ja, als het jou lukt om met bananen (glave wurms van de muta's, red.) een toren in de fik te krijgen in het echte leven vind ik je ook knap

Ik ben zelf trouwens niet 100% blij met de robots als ras. Ze moeten wel een organische 'baas' hebben ofzo (hoor ik 'Borg'?)

[Clay]

Borg zijn 1337
Heeft wel wat. elk voertuig is dan gewoon een andere maat borg-cube maar dan mogen de footmen wel "iets" harder lopen

[David]

We kunnen van ras 3 ook een ras maken dat alleen maar standaard units uitpoept in de basis, en dat al die unitjes zelf evolueren tot iets anders, maar dan op mechanische wijze. Ze staan met elkaar in contact via allerlei soorten straling (microgolf stralng voor energie-transport enzo). De mining-untis deployen zich op de resources en sturen ze door naar de basis die het weer verspreidt naar alle andere units.

[Clay]

schrijf je dit nog ergens op om later op terug te komen? anders is het straks vergeten op blz X in dit topic en doet niemand er meer wat mee, en dat zou zonde zijn Zo'n ras klinkt erg vet. Dan moet er ook goed geplaytest gaan worden om ervoor te zorgen dat het ras in balans is met de anderen (al is dat meer van belang voor MP, maar toch)

[David]

Waar is drm als je hem nodig hebt? Een centrale website voor Snowstorm waar we ideeën kunnen posten zou wel handig zijn op dit moment.

Ik zal het allemaal even opslaan in het goede oude notepad

Dat balanceren moet trouwens wel net zo goed als in Starcraft of Warcraft, die balance is echt subliem! Het lijkt me ook handig om te beginnen met een building tree oid. Ik ga morgen wel even wat tekenen (mijn tekenkunsten stellen niks voor, maar er is vast iemand ie het uit wil werken).

[Verwijderd]

php is alleen geschikt voor client/server connecties. Voor multiplier zul je moeten programmeren in C/C++/Java.

[[eNeRGy]]

Verwijderd schreef op 30 oktober 2002 @ 00:21:
php is alleen geschikt voor client/server connecties. Voor multiplier zul je moeten programmeren in C/C++/Java.

Met remote scripting en/of xml-rpc kan je makkelijk communiceren met de server tijdens het spel hoor.

[Woudloper]

Om erg lange discussie te voorkomen ben ik het met DiMension eens en wat Clay zegt met betrekking tot borg's vindt ik echt wel cool Naar mijn idee kunnen we daar wel voor gaan... Lijkt mij in principe wel een goed plan....

DHTML-en zoals DHTML-en bedoelt was....

[Verwijderd]

Ik lees dat jullie op zoek zijn naar een server ... ik heb een school server van 100 MB space, mysql server en php ondersteuning ... contact me als je het nodig hebt ... Waarschijnlijk kan ik ook wel bij de systeembeheerder voor elkaar krijgen om een snowstorm domeintje te maken ... ik hoor 't wel

[killercow]

dude server nodig?

ik heb een eigen colo bak met 50 gig per maand op een 10mbit lijn, is lang niet vol in gebruik.
volgende keer beter de topic lezen denk ik een eigen subdomein kan altijd

[Verwijderd]

yo gast; sorry dat ik het aanbied, maar goed have fun met je eigen colo bak met 50 gig per maand op een 10mbit lijn, die lang nog niet vol in gebruik is.

[drm]

</spannend verhaal>
server is nooit probleem geweest. Tijd is een probleem. Als je me honderd gig aan tijd kan geven, dan ben ik blij. Verder heb ik toegang tot de webserver van m'n bedrijf. And bow for me, for i am root. Dus niet meer over server zeikstralen, ajb

[Explore]

drm schreef op 30 oktober 2002 @ 10:58:
&lt;/spannend verhaal&gt;
server is nooit probleem geweest. Tijd is een probleem. Als je me honderd gig aan tijd kan geven, dan ben ik blij. Verder heb ik toegang tot de webserver van m&#039;n bedrijf. And bow for me, for i am root. Dus niet meer over server zeikstralen, ajb &gt;:)

Ditto, alleen zou ik niet de server van de zaak gebruiken voor een project als dit...

[killercow]

naja t maakt mij niet uit, ik dacht alleen dat als jullie er een nodig hebben dat er dan eventueel mochten er niet te veel mensen op hun teentjes getrapt zijn dat ik dan wel een beetje ruimte + bandbreedte kon vrijmaken, en dat mijn server mijn eigen server is en dat ik niet verantwoordelijk ben voor anderen/management/baas/ weet ik veel wie.

maar oke, ff ontopic.
verschillende layers met plaatjes maakt het samen met css plaatje rotaties+alpha enzo een hele makkenlijke manier om alle benodigde plaatjes te maken. ook levert het een simpele manier op om pc's met minder kracht het makkenlijker te maken. (kortom kun je ook op school snowstormen )

[Clay]

css plaatjes rotatie gaat niet werken omdat dat het perspectief vernaggelt. En bovendien is dat een IE filter, en ergens in het begin hadden we dacht ik besloten die niet te gebruiken.
Server gaat ook idd nog niet superhard boeien, en de game wordt in eerste instantie Single Player, dus over MP mag een ieder nadenken, maar of dat ook werkelijk gemaakt gaat worden is sterk te betwijfelen
Heeft er al iemand iets met een pathfind algoritme geprobeerd? daar moet iets mee te doen zijn met die laatste demo. En geef anders ook ff aan wat er mist (behalve docs dan )

[David]

IE filters zijn vies, dus die gebruiken we niet. En als we al dat soort dingen gaan gebruiken, kunnen we ook gewoon php voor alles gaan gebruiken.
Doen we dus niet.

Ik weet niet of we de discussie over rassen kunnen voorzetten en kijken wat iedereen er voor invulling aan wil geven.

Even een korte herhaling voor mensen die scrollmuis-RSI hebben:
1. De mensen
2. Natuurfreaks, en dan heb ik het niet over mensen die Groenlinks of SP stemmen, maar een ras dat niet mensachtig is (en niet elfs) en dat in harmonie met de natuur leeft
3. Robots of half-organisch, half-kunstmatige wezens. Ze hebben in ieder geval een levende leider.

Clay, we moeten trouwens wel vanaf begin af aan rekening houden met MP-functies. Ik ga me niet erg veel bezig houden met programmeren (dan loopt het zeker in de soep ), maar ik denk dat het wel mogelijk is dat vantevoren erin te betrekken.

[Clay]

Maar hoe maak je iets ueberhaupt multiplayer ?
Dat alleen lijkt me al lastig, en dit moet nog "realtime" ook.

Ik zou me dan zo voorstellen dat iemand server speelt, of dat er een master server is waar beide (of meer) spelers naar moeten connecten. het besturen van je units moet dan met een soort request via die server, zodat die server de uitkomst (die voor beide spelers natuurlijk identiek moet zijn) terugstuurt en dat de client dat dan zelf laat zien op het scherm. Maar dat betekent dat ALLES dan via die server moet.

Dan moet dus eigenlijk zelfs single player zo opgezet worden dat je zelf server speelt, en dat al jou gemuis en getyp als requests naar die server gestuurd wordt, anders moet je het 2 keer doen, 1 keer zonder server en 1 keer met, da's ook nix.

Maar ik blaat nu maar wat en weet dus verder niets van iets voor over een netwerk proggen kan je ueberhaupt met script een redelijke connectie leggen tussen 2 internetters?

[Woudloper]

Clay: Ik denk dat we het niet multiplayer moeten gaan bouwen. er worden dan namelijk teveel afhankelijkheden ingebouwd en dat komt de performance niet ten goede...

Met andere woorden. Laat het (naar mijn idee) maar gewoon singleplayer zijn. Dus jij speelt tegen de computer

[David]

Ok, dan geen multiplayer

Als we nou zelf AI-scripts kunnen schrijven en die loslaten op tegenstanders, is het toch nog wel een beetje multiplayer

[David]

Hoe gaan we trouwens de units visualiseren? Eerst in 3D modelleren en dan gewoon klein renderen, of teken en dan napixelen?

Ik heb zelf nog niet zo gek veel ervaring met modelleren in 3D en ik weet niet hoe het eruit ziet als je het op zo'n kleine schaal rendert.

[Explore]

In principe zou multiplayer wel mogelijk zijn. Wellicht maakt het de game-client (je lokale browser) een stuk lichter. Je kan de server al 't zware werk laten doen, zoals path-finding enzo. De server stuurt de lokatie van een unit dan naar alle clients die aan de server hangen (en in hetzelfde game zitten).

Wil dit een beetje vloeiend lopen, dan moet je wel met sockets werken, lijkt me, en dan is dhtml van de baan. ie: niet mogelijk... Dan zou je naar Flash moeten switchen. En zo kom je dan weer terecht bij de Flash-bridge, wat ergens in pagina 1 van dit topic al was afgekeurd, meen ik me te herinnerne.

Ik zou, zeker voor de eerste release, gewoon bij single-player blijven. Dwz: 1 persoon tegen een x aantal AI spelers.

[Verwijderd]

DiMension schreef op 03 november 2002 @ 13:48:
Hoe gaan we trouwens de units visualiseren? Eerst in 3D modelleren en dan gewoon klein renderen, of teken en dan napixelen?

Ik heb zelf nog niet zo gek veel ervaring met modelleren in 3D en ik weet niet hoe het eruit ziet als je het op zo'n kleine schaal rendert.

Dat wordt pixelen neem ik aan. Gifjes als sprites.
Schrijf er een contest voor uit, heb je weer een nieuw relaxed topic "Pixelate units voor "Snowstorm" ". Lijkt me wel lachuh, veel gasten op dit forum die niet mee kunnen denken met het spel, maar wel veel die kunnen pixelen (wie kan 't niet ).

[Clay]

kan je in JS ook niet een socket maken? stond me iets van bij dat ik een keer zoiets gezien heb op scottandrew.

[Explore]

Clay schreef op 05 november 2002 @ 10:24:
kan je in JS ook niet een socket maken? stond me iets van bij dat ik een keer zoiets gezien heb op scottandrew.

Ja, nu je 't zegt, die heb ik ook wel eens gezien... Ik heb alleen niet echt de indruk dat die full-proof is, zeg maar. Communicatie met de server stalled het de browser (en in ons geval het spel) wel...

Hier zijn twee links:

http://www.scottandrew.com/xml-rpc/
http://ashleyit.com/rs/

Zowiezo interessant speelgoed.

Overigens om nou te zeggen dat dit socket-programming is... Volgens mij niet: er staan wat scriptjes (php, perl, asp, whatever) op de server, die XML-requests van de client kunnen hanteren. Het is niet zo dat die scripts socket-servers zijn, maar gewoon scripts die vanuit Javascript worden aangeroepen, zonder het browserscherm te refreshen ofzo. Wel cool hoor, daar niet van...

[Verwijderd]

Bij q42 hebben ze ook iets. Kijk op deze site naar ICC, Inter Client Communication (bij demos en research). Het gaat om de files eventQueue en iccClient.

edit:
Nog ff linkjs naar .js files neergezet

[David]

Explore schreef op 09 November 2002 @ 14:37:
[...]


Ja, nu je 't zegt, die heb ik ook wel eens gezien... Ik heb alleen niet echt de indruk dat die full-proof is, zeg maar. Communicatie met de server stalled het de browser (en in ons geval het spel) wel...

fool-proof bedoel je?

offtopic:
Ik ben nu Tweakers.net infiltrant. Mocht je iets nodig hebben...

[oh,when?]

Verwijderd schreef op 09 November 2002 @ 15:00:
Bij q42 hebben ze ook iets. Kijk op deze site naar ICC, Inter Client Communication (bij demos en research). Het gaat om de files eventQueue en iccClient.

edit:
Nog ff linkjs naar .js files neergezet

links werken helaas niet meer. Bij Q42 maken ze trouwens echt toffe dingen, zo is hun XML editor Xopus echt geweldig, ik ben het momenteel aan het bekijken voor een project wat we aan het doen zijn. Er werken denk ik wel slimme mensen daar, zo volg ik de weblog van Sjoerd Visscher die nu bezig is met een nieuwe programmeertaal in Javascript, genaamd Loell nog heel basic allemaal, maar het begin is er.

...
When Dan Shappir and I were working on Beyond JS we agreed that Javascript is a powerful language. But we couldn't do all the tricks we wanted to do. One problem is the lack of control over the scope. And to keep the story short, I have created a language that gives full controle over scope: Loell.

Traditional languages either have static or dynamic scoping. With Loell you can have both. When a closure is created, the scope it is created in is stored in the scope property of the closure. When you use that scope when evaluating the closure (closure.scope#closure) you have static scoping. But when you use the current scope ($#closure) you get dynamic scoping. But you can use any object as scope.

It turns out that this is powerful enough to implement if, while the language has no actual branching built in. Even while is implementable which I had never anticipated.

I've got the parser running for just 3 days now, so Loell is nowhere near finished. There's no precedence and it's slow, but if you are interested in programming languages I hope you'll like to experiment with Loell already. If you know other languages that have special scope control, or research in scope control, I'd like to hear from you.

[Clay]

Je kan sicke dingen doen en je kan sicke dingen doen
melig eigenlijk. Je maakt wat in JS of je bent bezig, en dan kom je op een gegeven moment iets tegen dat ook makkelijker en "anders" zou moeten kunnen, nou dan maak je daar toch zelf wat voor Ik heb trouwens zelf niet zo'n mot met scopes dat ik er een nieuwe taal binnen js voor ga schrijven, wel voor formvalidatie gedaan trouwens

[Explore]

Maaruh... Snowstorm?

[David]

Geen tijd...
En mijn programmeerskills zijn om van te huilen (net als m'n tekenskills overigens)

De rassen werk ik nog wel verder uit, als iedereen het daarmee eens is (scroll maar een paar posts omhoog )

[Woudloper]

Explore: Maaruh... Snowstorm?

Wat bedoel je hiermee SnowStorm leeft nog steeds, hierover is al vaker binnen dit topic een opmerking over gemaakt, maar je moet het écht zo zien dat wij allemaal wel gewoon een baan of een studie ernaast hebben. Met andere woorden het staat niet op prioriteit één, maar komt wel op het prioritetenlijstje voor....

* Woudloper is bijvoorbeeld erg druk geweest de laatste tijd met het opleveren van een product (versie 1.1.) voor één van onze klanten. Dit heeft ervoor gezorgd dat ik de laatse mij eigenlijk meer bezig hebt gehouden met het lurken i.pv. het echt posten en het bezig zijn met 'SnowStorm'

[Explore]

Ja, dat snap ik - zie m'n subtitle. Ik ben druk bezig geweest met versie 1.0beta van een product voor de klant. Zit een jaar werk in. Ik dacht eindelijk eens een weekje vakanie te kunnen permiteren na een jaar hard werken, maar dat gaat dus niet door. De klanten stromen binnen en de projecten ook... Wie zegt nou dat 't slecht gaat in de IT? Ik werk me compleet 't schompes!

[David]

Explore schreef op 21 november 2002 @ 09:50:
Wie zegt nou dat 't slecht gaat in de IT? Ik werk me compleet 't schompes!

Check

[Verwijderd]

Ik vroeg me af of hier verder ooit nog wat mee gebeurt is,
En of iemand (van deze post) dit nog leest (als ik hier post).
Ik ben zelf namelijk al begonnen met een soortgelijk project (dune2)

dus...the point :
zijn hier nog mensen mee bezig ?

[Woudloper]

SneruaLBaL: natuurlijk zijn er nog mensen aan het werk op dit project (in de vrije tijd natuurlijk). Het is over het algemeen zo dat het een hele tijd rustende is en dan in één keer komt er weer een hele hoos aan informatie voorbij.

Voor de nieuwelingen is het zo dat drm nog een samenvatting van het één en ander zal maken. Als je de draad doorgelezen hebt, ben je hoogstwaarschijnlijk ook wel een link naar de website tegengekomen. Clay, is bezig het het maken van de engine waarop het spel gaat draaien, voor de W&G'ers onder ons, dat is natuurlijk Beehive. Een soortement van cross-browser API (of engine) waarmee je DHTML kan genereren.

Met andere woorden. Om een lang verhaal kort te maken. Ja, er zijn nog mensen mee bezig. Het is echter alleen zo dat het ons soms aan wat tijd schort en vandaar dat de draad soms een lange poos rustende is.

[CTVirus]

idd,

ff kijken of die engine er ooit nog gekomen is, weet iemand dat , clay??

[ Voor 93% gewijzigd door CTVirus op 02-01-2003 22:37 . Reden: volledigheid ]

[drm]

* drm heeft op 't moment andere dingen aan 't hoofd, dus zal er toch (helaas ) voorlopig geen tijd voor hebben.

Mochten er andere mensen zijn die e.e.a. aan site e/o samenvattingen op willen pakken, bij deze: ga je gang...

[Clay]

http://www.xs4all.nl/~peterned/got/snowstorm/

Dat is van een aardige tijd geleden (is toen ook gepost). Beehive (2) is inmiddels veel toffer geworden, en die zit daar nog niet in, maar ik heb het zelf ook aardig druk momenteel. Tentamens & afstuderen dus het zit er voor mij ook niet dik in dat ik er voorlopig veel aan kan doen.

http://www.xs4all.nl/~pet...nowstorm/overzichtje.html
(let wel 26 juli!!) is een kort beschrijvinkje, maar erg oud dus.

[Explore]

offtopic:
Coole nieuwe site, Clay! Wie heeft 'm ontworpen?
M'n vriendin, een pro-ontwerper, vind 'm ook erg mooi (en dat zegt wat)!

Maaruh, project snowstorm is dus toch dead...? Ik begrijp dat iedereen 't druk heeft (ik ook) en zo schiet het dus niet echt op.

[Clay]

Ik weet niet. Als het aan mij ligt is het nog niet dood nee, zeker niet, maar idd; druk druk druk. Ik moet nu gaan beginnen met afstuderen, krijg dus nog minder tijd en moet ook nog restantjes voor studie invullen. Verder kan ik qua coden eigenlijk alweer opnieuw beginnen, want ik ben nu met een 2D game engine bezig in js, en dat is eigenlijk al weer een veel beter aanpak dan wat er nu staat

offtopic:
Ja, is zelf ontworpen dank je.

[Explore]

Clay schreef op 02 February 2003 @ 19:19:
Verder kan ik qua coden eigenlijk alweer opnieuw beginnen, want ik ben nu met een 2D game engine bezig in js, en dat is eigenlijk al weer een veel beter aanpak dan wat er nu staat

Dat blijf je houden, he. Het kan altijd beter, handiger, sneller, gestructureerder, efficienter...

[Explore]

Zie hier. Misschien kunnen we die source porten naar javascript.

[himlims_]

_{loopt dit nog? ik zal in iemand z'n signature een link naar dit topic maar ... ja hoe actief is 't en hoe ver zijn jullie?}