[DHTML] Project "Snowstorm"

[Clay]

hmz.

Op die regel staat

JavaScript:

Unit.apply(this, arguments);

dat zorgt voor een deel van de overerving, en da's nogal belangrijk domper als dat niet werkt, ik dacht dat apply het overal wel op deed ... volgens mij kan zelfs NS4 dat.

edit:


win2k ie5.5 werkt het wel

[Verwijderd]

dan up je de specs toch? IE 5.5 is een heel redelijke ondergrens voor zoiets dat in potentie zeer ingewikkeld kan worden (understatement?). Het doet het hier perfect in Phoenix (Mozilla 1.2b) en IE 6, zeer soepel in beide browsers.

[LuCarD]

Yogho schreef op 01 oktober 2002 @ 12:46:
Clay:

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

Ik zit op win2k + IE5

Bij mij werkt het wel.....

ook W2k + IE5

[OkkE]

Misschien nutteloos om te vermelden, maar anyway:
Hier met W2K + IE6 werkt het.

[Verwijderd]

Ik heb eens een workaround voor Function.call. Deze werkt op IE4;5;5,5;6/Win, IE5/Mac, Mozilla. Als de method niet bestaat, wordt deze "aangemaakt".

Let wel, hij is nog niet compleet, er worden geen variabelen meegegeven. Function.apply is vergelijkbaar, maar deze gebruikt een array als argumenten-lijst, ipv een "gewone" argumentenlijst.

JavaScript:

if(!Function.call) Function.prototype.call = function(THIS)
{
  if(!THIS) { alert('First argument needs to be the owner object (this)'); return; }
  THIS.$call=this;
  return THIS.$call();
}

[drm]

mja, workarounds gaan alleen maar ten koste van de performance. wat mij betreft liggen de requirements dan gewoon wat hoger.

* drm heeft overigens nog geen tijd gehad de source te bekijken, maar zal 't vanavond zeker doen

[Bosmonster]

Misschien handig voor inspiratie:

http://www.smokymonkeys.com/triglav/

Een RPG in JS

[Verwijderd]

drm schreef op 01 oktober 2002 @ 14:27:
mja, workarounds gaan alleen maar ten koste van de performance. wat mij betreft liggen de requirements dan gewoon wat hoger.

Helemaal mee eens, maar ik had gehoopt dat iemand een ideetje had om die variabel aantal parameters mee te geven

_{BTW, IE5/Win2K crasht toch veel te vaak op GoT}

[Clay]

Bosmonster schreef op 01 oktober 2002 @ 14:30:
Misschien handig voor inspiratie:

http://www.smokymonkeys.com/triglav/

Een RPG in JS

Dat is ziek
Graphics zijn extreem vet ook.
code is ook behoorlijk netjes

[drm]

wow, die gfx zijn echt

[Woudloper]

Heb ook net ff die van smokeymonkeys gespeeld... Die is echt gaaf

Maar, wij zijn zo goed dat kunnen we vast beter... Moeten we degene die het grafische werk gaan doen wel hard aan de gang zetten,want als ik dat zo zie moet er nog veel gedaan worden...

Wellicht kunnen we trouwens wat problemen welke wij hadden bekijken hoe ze het daar hebben opgelost of gaan we net zolang door totdat we het zelf hebben uitgevonden...

* Woudloper persoonlijk gaat voor het laatste... Net zolang doorgaan totdat we het zelf hebben uitgevonden... leer je ook het meest van

[David]

Niet afkijken, gewoon zelf doen inderdaad. Met een klein beetje denkhulp van Reaper_One heb ik in ieder geval een manier bedacht om via de X en Y-coordinaten van je muis te bepalen boven welke tile je zit. Ik zal er eventjes wat illustraties bij maken om het uit te leggen (is een beetje moeilijk uitleggen anders).

Dan nog even een vraagje: moeten we alleen weten wat de isometrische X en Y zijn van de tiles, of moeten we precies weten waar op de tile (dus de 30 graden gedraaide X en Y coordinaten)? Dat laatste is iets moeilijker gok ik.

[Clay]

de units zullen gewoon op basis van normale X en Y over het veld moeten bewegen, dat kan immers niet anders, en verder moeten DIE X en Y gebruikt kunnen worden om te kijken boven welke tile een unit staat. leek mij zo verder zijn er op zich niet echt veel meer wazige coordinaten nodig. We kunnen gewoon zelf ons coordinatenstelsel bedenken, dus dan zou ik het maar meteen zo makkelijk mogelijk doen, niet?

[David]

Dan gaan we voor de simpele (* David veegt het zweet van z'n voorhoofd.)
Plaatje komen morgen wel (nu geen zin meer in)

[oh,when?]

* oh,when? bekijkt het allemaal vanaf een afstandje en springt wel in als ie echt wel wat nuttigs te melden heeft.

2 opmerkingen:

- Clay kun jij een model / schema maken van hoe jij de engine zou zien? Dus een main engine en overerving door andere classen
- Dat smokeymonkey spel is echt mooi gedaan hele slicke gfx ook. thnx voor de tip!

[drm]

oh,when?:
- Clay kun jij een model / schema maken van hoe jij de engine zou zien? Dus een main engine en overerving door andere classen

da's dus exact wat ik wilde zeggen
Verder had ik nog 2 opmerkingen:
Clay: nicely done, dat grouping mechanisme.

Ik ben ondertussen ook bezig met 't hele topic doorlopen op alle linkjes en interessante stukjes tekst, om ff te verzamelen op een site. Dat kan ik redelijk binnenkort af hebben. Dan hebben we iig een iets meer geconcentreerd punt van gegevens

[UDuckling5]

Ben ik de enige bij wie die game niet werkt? Hij blijft hangen op het punt nadat ik het mannetje heb geselecteerd...

[David]

UDuckling5 schreef op 02 oktober 2002 @ 20:05:
Ben ik de enige bij wie die game niet werkt? Hij blijft hangen op het punt nadat ik het mannetje heb geselecteerd...

Welke browser/OS gebruik je? En heb je alle onderdelen van DHTML aanstaan (Javascript en CSS)? Onder Mozilla 1.1 @ WindowsXP SP1 en IE6 @ WindowsXP SP1 werkt alles perfect.

[David]

Tijd om over units te gaan denken! Of zullen we beginnen met een verhaal?

[drm]

je doet je sig geen eer aan

[David]

drm schreef op 07 oktober 2002 @ 14:15:
je doet je sig geen eer aan

't is gelukkig geen lijfspreuk, integendeel zelfs. Ik vond hem alleen wel grappig.

Willen we trouwens een complete Starcraft rip-off maken? Met 3 rassen enzo? Ik ben persoonlijk voor een originelere aanpak (zonder carriers maar met Siege Tanks )

Ik ga nog ff verder denken en iets uitschrijven ofzo. Ik ben alleen niet zo'n goede concept-art tekenaar, dus zouden mensen die daar wel goed in zijn zich even willen melden.

[Woudloper]

DiMension schreef op 07 oktober 2002 @ 15:27:Ik ga nog ff verder denken en iets uitschrijven ofzo. Ik ben alleen niet zo'n goede concept-art tekenaar, dus zouden mensen die daar wel goed in zijn zich even willen melden.

Maakt niet uit Je begint gewoon, gooit het in de groep (lees: topic) en dan wordt er vanzelf op geschoten, ofwel er wordt op aanpassingen aangestuurd e.d.

[Explore]

Zijn jullie nou al 4 maanden bezig en nog geen concept? Hm... Ik ben niet sceptisch ofzo, hoor... En dat terwijl Peter Nederlof meewerkt (coole site!)

[David]

Explore schreef op 09 oktober 2002 @ 17:43:
Zijn jullie nou al 4 maanden bezig en nog geen concept? Hm... Ik ben niet sceptisch ofzo, hoor...

Gelukkig zijn wij ook niet sceptisch .
Spit voor de gein het hele topic maar eens door. Er is al veel werk verzet. En natuurlijk zijn we niet 4 maanden non-stop bezig (er wordt soms dagen niet gereageerd). Toch zijn er een aantal mensen wel mee bezig. Ik denk dat er binnenkort wel een storylinetje verschijnt van mijn kant, en dan kunnen we daar weer over gaan discussieren.

Denk dus even na en kijk even rond voordat je dit soort dingen gaat roepen. We hebben geen deadline te halen en iedereen doet dit voor z'n plezier. Er is dus geen haast bij.

Explore schreef er even bij:
En dat terwijl Peter Nederlof meewerkt (coole site!)

Hij is wel zo'n beetje hét javascript-brein in dit project. Ik vrees dat mijn javascript-capaciteiten niet voldoende zijn (ik ben zeg maar begrijpend lezer ). Maar een goede scriptert betekent nog geen razendsnel project. En dat hoeft gelukkig ook niet.

[drm]

tja 't blijft een hobby-projectje voor "d'rbij" he

[Explore]

DiMension schreef op 09 oktober 2002 @ 17:51:
[...]


Gelukkig zijn wij ook niet sceptisch .
Spit voor de gein het hele topic maar eens door. Er is al veel werk verzet. En natuurlijk zijn we niet 4 maanden non-stop bezig (er wordt soms dagen niet gereageerd). Toch zijn er een aantal mensen wel mee bezig. Ik denk dat er binnenkort wel een storylinetje verschijnt van mijn kant, en dan kunnen we daar weer over gaan discussieren.

Denk dus even na en kijk even rond voordat je dit soort dingen gaat roepen. We hebben geen deadline te halen en iedereen doet dit voor z'n plezier. Er is dus geen haast bij.

Ik geef toe dat ik niet heel het topic gelezen heb. Ik denk alleen dat je moet uitkijken dat het niet doodbloed. Wees blij dat je geen deadline hebt, aan de ene kant, aan de andere kant is het een stimulus om daadwerkelijk stukken code in elkaar te gaan zetten enzo.

Hij is wel zo'n beetje hét javascript-brein in dit project. Ik vrees dat mijn javascript-capaciteiten niet voldoende zijn (ik ben zeg maar begrijpend lezer ). Maar een goede scriptert betekent nog geen razendsnel project. En dat hoeft gelukkig ook niet.

Het leek me wel leuk om hier aan mee te werken, maar ik vraag me af wat ik bij kan dragen (als programmer) als hij al meedoet.

Beehive zorgt al voor 't meeste zware werk, denk ik. Bovendien zei iemand in een andere thread al dat 'mijn kennis niet serieus hoeft te worden genomen', dus och...

[Woudloper]

Explore schreef op 10 oktober 2002 @ 11:12:Ik geef toe dat ik niet heel het topic gelezen heb.

Dat is dom natuurlijk Als je dat wel had gedaan was je namelijk ook linkjes tegengekomen met samenvattingen e.d.

Ik denk alleen dat je moet uitkijken dat het niet doodbloed. Wees blij dat je geen deadline hebt, aan de ene kant, aan de andere kant is het een stimulus om daadwerkelijk stukken code in elkaar te gaan zetten enzo.

Ik denk niet dat je je zorgen hoeft te maken dat het doodbloek, want er zijn hier genoeg mensen (GoT-ers) geïnteresseerd zodat dat niet gaat gebeuren....

Het leek me wel leuk om hier aan mee te werken, maar ik vraag me af wat ik bij kan dragen (als programmer) als hij al meedoet.

Genoeg, iedereen kan bijdragen. Er zijn en blijven genoeg vraagstukken over hoe één en ander te realiseren. Lees o.a. het draadje maar eens door op de algoritme e.d.

Beehive zorgt al voor 't meeste zware werk, denk ik. Bovendien zei iemand in een andere thread al dat 'mijn kennis niet serieus hoeft te worden genomen', dus och...

In principe is dat onzin. Iedereen zijn kennis kan bijdragen aan het project. De minder ervaren mensen kunnen de ervaren mensen triggeren om na te denken over zaken waar zij zelf uit ervaring over heen kijken e.d. Dus ik zou zeggen: hou het draadje in de gaten en kijk maar waar je bij zou kunnen dragen

[drm]

Explore >

Over de deadline: je hebt wel gelijk, maar een deadline hiervoor stellen is niet reeel. Daarvoor is het project te slecht te overzien, en is het voor te veel mensen gewoon iets waar ze af en toe een uurtje in kunnen steken. Ikzelf heb zo verrot weinig tijd dat zelfs die website nog uit april ofzo stamt. Ben ondertussen met een wat beter overzicht bezig van wat er nou gezegd en afgesproken is, maar dat is ook nog niet af.

Probleem ligt wat dat betreft in de management hiervan. Die is er namelijk niet. Op den duur zullen knopen doorgehakt moeten worden, en ik denk dat wat dat betreft iedereen daarover zijn mond open kan trekken, als hij/zij denk dat 't anders doodbloedt. Als 't aan mij zou liggen was het over een jaar nog niet klaar, maar gelukkig ben ik niet de enige die hieraan deelneemt.

Kortom: hoe meer zielen hoe meer inzichten, hoe meer inzichten hoe beter 't perspectief. welkom, zou 'k zeggen.

_{en nou weer ontopic}

[Clay]

Beehive(2) doet alleen de "grafische" onderlaag. Het is (denk ik iig) in een project van deze omvang zowiezo belangrijk om alles zo veel mogelijk te scheiden en modulair op te zetten, en daarom zou een letterlijke "getElement... .style.top = '.. " binnen bijvoorbeeld de MarnineObject.move() functie een ontoelaatbare vertroebeling van code zijn, vandaar dat er in dat selectie en beweging voorbeeld een soort "sprite" in de marine zit, en die heeft weer een eigen moveTo.

De logica van het spel zelf wordt veel meer werk, objecten, regels, ai enz. Beehive kan alleen maar layers aanpassen En ik ben heus niet de enige "scriptgoeroe" in /13

Doodbloeden is inderdaad misschien wel een reeele dreiging, of misschien niet doodbloeden maar in ieder geval dat het nog heel lang gaat duren voordat er iets speelbaars is, laat staan tot het af is (niet dat dat erg is). Toch, met regelmatige input van verschillende kanten denk ik dat dit nog best lang door kan gaan We zijn al sinds juni bezig, en ik wil het alles behalve dood noemen. Verder moet je ook maar net tijd hebben om wat te doen met een drukke baan of studie erbij is het denk ik voor niemand leuk om keiharde deadlines te stellen met "anders lig je eruit". 't is immers allemaal voor de lol bedoeld.

[Verwijderd]

wie waren ook al weer de pixelneukhelden van tweaktown? XLerator, Nozzman en Spiney voornamelijk meen ik. Als de standaard formaten van een unit bekend zijn kunnen er al mensen (oa bovenstaande) aan graphics beginnen, dan is weer een visuele milestone gehaald en krijgen mensen vanzelf meer enthousiasme denk ik.

mischien moeten er nog wat dingen afgesproken worden over kleurdiepte, transperantie en bestandsformaat enzo, misschien kunnen heel wat regeltjes van tweaktown kopieren wat dat betreft

[Explore]

Ik wou niet suggereren dat je een deadline moet stellen dit spel. Dat lijkt me inderdaad niet fijn voor een project als dit. Helaas heb ik het zelf ook enorm druk, maar af-en-toe meedenken over een algoritme is alleen maar leuk. Ik zal eerst (later) eens de hele thread doorlezen. Ik zag al iets over positie van een object op een tile (en/of op welke tile deze staat). Dat is dus inderdaad - zoals iemand al uitwerkte - niet zo moeilijk om te bepalen.

code:

tilex = xposobject / tilewidth;
xpos_on_tile = xposobject % tilewidth;

en hetzelfde voor y.
En als de zaak onder een hoek staat, moet er nog wat gerommeld worden met cos en sin. Maar alvorens ik meer onzin uitkraam zal ik de thread 'even' doorlezen...

[oh,when?]

Clay schreef op 10 oktober 2002 @ 12:13:
Beehive(2) doet alleen de "grafische" onderlaag.

Kunnen we niet Beehive 2 Lite inzetten?

[David]

Explore schreef op 10 oktober 2002 @ 12:53:

code:

tilex = xposobject / tilewidth;
xpos_on_tile = xposobject % tilewidth;

en hetzelfde voor y.
En als de zaak onder een hoek staat, moet er nog wat gerommeld worden met cos en sin. Maar alvorens ik meer onzin uitkraam zal ik de thread 'even' doorlezen...

Dat eerste gedeelte is het simpelste
De rest heb ik ook al uitgewerkt. Ik neem aan dat we uitgaan van tiles die twee keer zo breed zijn als hoog (net als in het eerste voorbeeld van Clay).

Even wat afspraakjes:
X en Y (hoodletters) zijn de coordinaten van de rechthoekige tile (tweede tile van links heeft bijvoorbeeld coordinaat 1,0)
x en y (kleine letters) zijn de coordinaten binnen een tile. x+1 betekent 1 pixel naar rechts. y+1 betekent 1 pixel naar beneden.

Je doet het volgende: |2y| + |x|. Als dat groter is dan 196 dan zit je op de isometrische tile die coordinaten X+1 en Y+1 heeft. Is het kleiner dan 64 dan zit je op tile X-1, Y-1.


Door de x en y om te draaien (x/=tilewidth en x/=tileheight) kun je checken op de andere twee tiles.

Ik denk dat dit een redelijke manier is om uit te zoeken op welke tile een unit o.i.d. staat. Geen sinussen of cosinussen nodig.

[Verwijderd]

Als ik dit zo allemaal hoor, zou ik zeggen dat jullie mijlpalen moeten stellen: een doel waar je naartoe werkt, want het einddoel is wel errrug ver weg...
Een doel zou kunnen zijn een werkende engine, zonder al te veel optimalisaties, en met een minimum aan opties (en formuleer deze opties, type es een rijtje in). Daarnaast natuurlijk specs opstellen voor de graphics: dan kan iemand graphics maken.

[Clay]

oh,when? schreef op 10 oktober 2002 @ 19:18:
[...]


Kunnen we niet Beehive 2 Lite inzetten?

Je doelt niet toevallig op die 700 bytes versie? mjah, dan kunnen we kijken of we met snowstorm aan de volgende the5K mee kunnen doen

[UDuckling5]

Als we nu ook vast afspraken maken over hoeveel units en wat voor units (en ook gebouwtjes) we willen, kan er vast een Ladder of Tree gemaakt worden (dat is fijner met het overzicht )

En voor het verhaal, geef eens wat dingen die er per sé inmoeten (3 rassen? e.d.) dan kan ik daar mijn creativiteit op botvieren.

[oh,when?]

Clay schreef op 10 oktober 2002 @ 21:24:
[...]


Je doelt niet toevallig op die 700 bytes versie? mjah, dan kunnen we kijken of we met snowstorm aan de volgende the5K mee kunnen doen

jaaaaaaaaaah!

zie je dat we steeds onze grenzen verleggen hier?

[Annie]

UDuckling5 schreef op 11 oktober 2002 @ 06:40:
geef eens wat dingen die er per sé inmoeten

minstens 1 geinige easter-egg.
* Annie loves easter-eggs

offtopic:
heeft iemand misschien compromiterende foto's van Clay die we kunnen inbakken

[David]

Annie schreef op 11 oktober 2002 @ 11:48:
[...]

minstens 1 geinige easter-egg.
* David loves easter-eggs

offtopic:
heeft iemand misschien compromiterende foto's van Clay die we kunnen inbakken

Eentje lijkt me wat weinig. Zeker als we een Starcraft rip-off maken

Ik denk zelf dat 3 rassen wel redelijk ideaal is. Ik ben al aan het proberen een gigantisch originele storyline te bedenken. Schiet alleen nog niet zo op

[Explore]

Ik ben nog - vol goede moed - bezig met het topic doorlezen, maar kom helaas telkens links tegen die niet meer werken. Dit is eeuwig jammer. Kunnen al die stukjes code, plaatjes ed. die mensen in elkaar flansen niet ergens op de site die inmiddels al gereserveerd bij elkaar worden gezet?

Het gaat hier dus over rijdende tankjes van Limhes en uitleg over de isometrische map op 3 mehoden van Clay. Ik heb nu dus geen idee wat er allemaal al is uitgezocht... Deze info is verloren gegaan, ofzo?

Had drm zichzelf niet als webmaster opgeworpen?

[Verwijderd]

Yogho schreef op 01 oktober 2002 @ 12:46:
Clay:

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

Ik zit op win2k + IE5

Ik heb em ook ff getest
Win 98,
mozilla 1.2a: perfect
ie 6.0: ook lekker

Enige wat ik een beetje vreemd vind dat ze over een lange afstand steeds sneller bewegen...dat is een beetje weird, maar voor de rest toppie

[David]

Verwijderd schreef op 12 oktober 2002 @ 17:06:
[...]
Enige wat ik een beetje vreemd vind dat ze over een lange afstand steeds sneller bewegen...dat is een beetje weird, maar voor de rest toppie

Dat is al uitgelegd. Over alle afstanden doen de 'units' 1 sec. Op een lange afstand zullen de units dus sneller bewegen.


Over de website: drm, flans jij die ff in elkaar? Als je echt geen zin/tijd hebt zal ik wel kijken of ik dat kan doen. Er zijn hier vast ook wel andere mensen die mee kunnen helpen (we zitten niet voor niks in W&G)

[maratropa]

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.

bijvoorbeeld

[Mithrandir]

gladiool schreef op 12 oktober 2002 @ 18:22:
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.

bijvoorbeeld

[afbeelding]

Is dat warcraft-style? Nee? Hoeft niet

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

-dit is geen vermomde schop hoor -

Over path-finding algoritmes: ik vind het 'manhattan-style' algoritme erg mooi. Moet een speler letten op z'n tanks als 'ie ze het SNELST ergens heen wil sturen.
Wat voor algoritme gebruikt warcraft eigenlijk?

[David]

Hey gladiool, ik heb wat van je werk gezien en ben zeker onder de indruk. Ik ga zelf ook aan de slag met 3D-modeling (voor websites, voor de fun en natuurlijk voor Snowstorm).

Ik denk dat we eerst iets van een verhaal moeten hebben (ja, ik ben ermee bezig ) en dan pas na kunnen gaan denken over units. Plaats maar een soort van gallerijtje ofzo dat we kunnen uitkiezen

[Explore]

killercow schreef op 10 september 2002 @ 13:06:
ps weet iemand hier hoe je vectoren enzo doet?
dus hoe ik de lichtsterkte op een bepaald vlak kan uitrekenen?

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'.

[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?