[DHTML] Project "Snowstorm"

[drm]

Naar aanleiding van wat verloren posts tussen de onzin en prijsbetuigingen in [topic=484706], bij deze het topic om een nieuw project te initieren.

Clay kwam met het idee om een StarCraft-achtige DHTML-game te maken. Hij acht dit haalbaar, en met hem een aantal anderen. Hoe lang het gaat duren boeit (mij) niet. Als 't maar wat wordt

Dit topic is er natuurlijk voor om even wat dingen op een rij te zetten. En dat begint natuurlijk met een brainstorm.

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

Ga jullie gang



________________________________________________________________________
Alvast wat users die gezegd hebben mee te willen doen (in no "particular" order):

• Clay (zet documentatie/plan van aanpak op?)
• Blues (AI?)
• oh,when?
• r0bert
• Woudloper
• Yogho
• Annie(geluidjes en beta-testing? )
• Pelle(pessimist )
• drm (draait alvast ff een siteje in elkaar)

[Clay]

whoa dit topic had ik wat later verwacht maargoed.

Het lijkt mij iig handig om eerst gewoon inderdaad te gaan brainstormen, ideeen spuien over speelstijlen/regels, graphics, rassen, single/multiplayer en mogelijkheden, even nog zonder na te denken over de praktische haalbaarheid ervan, dat komt later wel

Multiplayer zou natuurlijk het leukste zijn al is dat denk ik wel iets waar de haalbaarheid als eerste in acht moet worden genomen. Indien dat niet lukt moet er gewoon een vette sp-campaign in elkaar gedraaid worden die uitdagend en leuk is, een verhaal met wat achtergronden is dus denk ik het eerste wat er komen moet

Op basis van de bedachte wereld, units en items (en wat er verder nog uit komt) wil ik dan wel een basis class-model bouwen en een eerste opzet van de "engine" in js coden. object based met zo volledig mogelijke inheritance, zodat het tevens ook een inleiding wordt voor diegenen die hier nog niet echt mee in aanraking zijn geweest en nog voornamelijk met grote array structuren werken.

Hier wil ik het nu ff bij laten, want het is laat en ik hen (te) veel bier op

[Pelle]

Dude, je vergeet mij

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

Laten we beginnen met iets simpels, en dat eventueel uitbouwen tot iets dat meer functionaliteiten biedt. Niet dat ik alle mooie en gave ideeen nu al de grond in wil boren, maar ik zou het ook zonde vinden als er straks zulke torenhoge verwachtingen komen van iets dat wellicht niet te realiseren is.

Dusse, count me in in ieder geval

[drm]

Pelle:
Dude, je vergeet mij

Had je niet iets zien zeggen over meedoen sorry

ik zou het ook zonde vinden als er straks zulke torenhoge verwachtingen komen van iets dat wellicht niet te realiseren is.

Ik heb meteen maar ff een beginnetje gemaakt met een site.
http://gerard.yoursite.nl/got/project-starcraft/

[Karp]

Ik wil helpen!


maar ik kannie scripten....
uhmmm...

brainstormen dan?

[Woudloper]

Cool....

dit had ik echt niet verwacht, dat het al zo snel van start zou gaan

Maar even in kader van het 'Front spel nicknames goed', kan je mijn nick nog even aanpassen....

Ik wacht de verdere ontwikkelingen wel af... Heb de thread al toegevoegd aan de 'GOT-Tracker'

[Verwijderd]

Op donderdag 13 juni 2002 00:30 schreef Clay het volgende:
Multiplayer zou natuurlijk het leukste zijn al is dat denk ik wel iets waar de haalbaarheid als eerste in acht moet worden genomen. Indien dat niet lukt moet er gewoon een vette sp-campaign in elkaar gedraaid worden die uitdagend en leuk is, een verhaal met wat achtergronden is dus denk ik het eerste wat er komen moet

Mee eens, ik zei wel vol bravoure dat ik de AI wilde gaan doen, maar ik heb niet voor niets m'n studie niet afgemaakt Ik denk dat een goede object-oriented single player opzet later altijd nog wel een AI-opponent toestaat. Dit betekent natuurlijk niet dat er helemaal geen AI in komt. Op het moment dat je je troups ergens naartoe stuurt, moeten er ook een algoritme in actie komen dat de units om obstakels heen stuurt e.d.

Op donderdag 13 juni 2002 00:30 schreef Clay het volgende:
[..] het is laat en ik hen (te) veel bier op

Da's wel duidelijk

/me vraagt zich af of hij de enige in het project is die zowel War- als Starcraft nooit heeft gespeeld.

[Bosmonster]

Asl het enigszins modulair opgebouwd gaat worden dan wil ik er ook nog wel aan meeprutsen

Hoewel ik weet hoe onze laatste samenwerkingspoging (lees: BeeHive) afgelopen is..

Volgens mij staat die account op Sourceforge nog open

[edit]
OW hier istie:

http://sourceforge.net/projects/scriptbees/

[Verwijderd]

Ik heb het hier al eens met Clay over gehad via de ICQ De grootste problemen liggen volgens mij bij het definieren van paden op een map.

Dat een unit dus om een plas water heen gaat ipv eroverheen. En dan daarbij nog rekening houdend dat je vantevoren een "kortste weg" moet gaan berekenen.

Op zich kun je dit wel doen met sprites, en een achterliggende laag onder de map, met 0en en 1en, waarbij dit de verboden gebieden worden

Maar vooral dat algoritme zal het moeilijkst worden.

[Pelle]

Op donderdag 13 juni 2002 09:34 schreef Blues het volgende:
/me vraagt zich af of hij de enige in het project is die zowel War- als Starcraft nooit heeft gespeeld.

* Pelle heeft zowel War- als Starcraft gespeeld

Maar Starcraft was dus veeeel en veel cooler. Veel beter dan de Command & Conquer en Red Alert varianten die er in de loop van de jaren verschenen zijn.

[Verwijderd]

/me is groot fan van het RTS genre

/me heeft ook 20+ originele RTS games nog in doos

[Bosmonster]

Op donderdag 13 juni 2002 10:49 schreef Gordijnstok het volgende:
Ik heb het hier al eens met Clay over gehad via de ICQ De grootste problemen liggen volgens mij bij het definieren van paden op een map.

Dat een unit dus om een plas water heen gaat ipv eroverheen. En dan daarbij nog rekening houdend dat je vantevoren een "kortste weg" moet gaan berekenen.

Op zich kun je dit wel doen met sprites, en een achterliggende laag onder de map, met 0en en 1en, waarbij dit de verboden gebieden worden

Maar vooral dat algoritme zal het moeilijkst worden.

Daar zijn kant en klare pathfinding algoritmes voor te vinden op internet.

[Verwijderd]

Dan blijven nog een hoop punten over

1) Performance
2) AI
3) Verhaal
4) Platform
5) Top-down view of met een lichte angle ?
6) Tegen de computer? Of multiplayer?
7) etc.

[Pelle]

Op donderdag 13 juni 2002 10:57 schreef Bosmonster het volgende:
Daar zijn kant en klare pathfinding algoritmes voor te vinden op internet.

Inderdaad, met een goeie recursieve pathfinding functie kom je overal, mits het betreffende doel natuurlijk niet onbereikbaar is

Desalniettemin is het natuurlijk wel leuk om zelf zo'n algoritme te verzinnen in plaats van een ge-eikte methode te gebruiken.. dat kan altijd nog, als je eigen pogingen jammerlijk falen zegmaar

[Verwijderd]

Op donderdag 13 juni 2002 11:03 schreef Pelle het volgende:

[..]

Inderdaad, met een goeie recursieve pathfinding functie kom je overal, mits het betreffende doel natuurlijk niet onbereikbaar is

Desalniettemin is het natuurlijk wel leuk om zelf zo'n algoritme te verzinnen in plaats van een ge-eikte methode te gebruiken.. dat kan altijd nog, als je eigen pogingen jammerlijk falen zegmaar

Mja, maar waarom opnieuw het wiel uitvinden zegmaar Met al die andere punten ben je ook nog wel een tijdje bezig

Imo, kun je maar beter zoveel mogelijk gebruik maken van bestaande algoritmes en objecten Het moet ooit is een keer af, en als je dat ook nog allemaal moet gaan ontwikkelen ben je nog eeuwen bezig

[Verwijderd]

Op donderdag 13 juni 2002 10:57 schreef Bosmonster het volgende:
Daar zijn kant en klare pathfinding algoritmes voor te vinden op internet.

Fetishcoder heeft hier ergens nog een loeisnelle A* variant in C liggen. Die had ie ooit precies voor pathfinding in een RTS-type game geschreven.

[Verwijderd]

Tof !
Ik zal dit topic ook wel in de gaten houden, en als ik wat nuttigs weet zal ik dat wel ff posten..

Betreffende de korste route, en de paden kom je volgens mij gewoon terecht bij een Dijkstra Algoritme. Zijn wel lastig uiteraard, maar het wiel hoef je niet opnieuw uit te vinden. Weet alleen niet of dergelijke algoritmes ooit al zijn geimplementeerd binnen JS.

[Verwijderd]

Op donderdag 13 juni 2002 11:16 schreef Blues het volgende:

[..]

Fetishcoder heeft hier ergens nog een loeisnelle A* variant in C liggen. Die had ie ooit precies voor pathfinding in een RTS-type game geschreven.

Heeft hij er problemen mee deze sourcecode hier openbaar te maken, zodat we deze kunnen porten naar JavaScript indien mogelijk

[Bosmonster]

Ik neem ook aan dat het IE6+ wordt?

Mozilla 1.0 is nog te traag/buggy met veel dhtml en de oudere IE5.0 is ook niet alles.. (5.5 is wel redelijk)

Uiteraard volledig DOM-compatible, maar er zitten nog steeds behoorlijk implementatieverschillen in de verschillende browsers.

[Woudloper]

Als we voor Multiplayer gaan dan moet er dus ook server-side coding bij komen... Wie gaat dat dan voor zijn rekening nemen... Heb alleen kennis van ASP en PHP maar een heel klein beetje....

Maar we moeten natuurlijk eerst de basis hebben en Pelle (pessimist volgen drm ) heeft wel gelijk dat we niet meteen te veel willen, want het doodbloeden komt dan wel ter sprake....

Gelukkig zijn er nu redelijk wat mensen aanwezig met het schrijven en denken hoe het kan om een DHTML game te schrijven, dus dat zit wel goed...

Als er met het daadwerkelijke coden begonnen gaat worden, moet er zeker een goede modulaire opzet zijn zodat verschillende personen de verschillende modules kunnen schrijven... Dus functioneel ontwerp e.d.

Wow, zo begint het dus nog een echt project te worden

[Bosmonster]

Op donderdag 13 juni 2002 11:54 schreef Woudloper het volgende:
Als we voor Multiplayer gaan dan moet er dus ook server-side coding bij komen... Wie gaat dat dan voor zijn rekening nemen... Heb alleen kennis van ASP en PHP maar een heel klein beetje....

Maar we moeten natuurlijk eerst de basis hebben en Pelle (pessimist volgen drm ) heeft wel gelijk dat we niet meteen te veel willen, want het doodbloeden komt dan wel ter sprake....

Gelukkig zijn er nu redelijk wat mensen aanwezig met het schrijven en denken hoe het kan om een DHTML game te schrijven, dus dat zit wel goed...

Als er met het daadwerkelijke coden begonnen gaat worden, moet er zeker een goede modulaire opzet zijn zodat verschillende personen de verschillende modules kunnen schrijven... Dus functioneel ontwerp e.d.

Wow, zo begint het dus nog een echt project te worden

Multiplayer is leuk, maar dan zal het wel een volwaardige serverapplicatie moeten worden en geen 'pagina-generatie' taal zeg maar

Ik kan wel een multi-threaded servertje schrijven in Java ofzo, maar hoe implementeer je in hemelsnaam zoiets in HTML Met Flash heb je nog XML functies...

[Pelle]

Multiplayer lijkt me nog te lastig; tenminste, ik stel me erbij voor dat we eerst zorgen dat de speler zelf 2 tegenstanders aan kan sturen en dus tegen elkaar kan laten spelen. De lol daarvan is natuurlijk ver te zoeken, want je wint altijd, maar als dat eenmaal werkt kun je na gaan denken over hoe je die tegenstander gaat vervangen door een AI of een tegenstander ergens aan de andere kant van de wereld.

[Verwijderd]

Op donderdag 13 juni 2002 11:55 schreef Bosmonster het volgende:
Multiplayer is leuk, maar dan zal het wel een volwaardige serverapplicatie moeten worden en geen 'pagina-generatie' taal zeg maar

Met PHP/ASP kun je imho zeker niet goed een multiplayer versie opzetten.
Tenzij er alleen sprake is van een scorebord o.i.d.

[Clay]

javascript kan ook met xml overweg da's wel IE only, maar ik koester toch niet de valse hoop dat dit op enig andere browser gaat werken dan IE, netscape 4 is sinds enkele dagen officieel 5 jaar oud en mozilla trekt het gewoon niet als je veel layers wil bewegen.

Performance maak ik me op zich niet al te veel zorden over. Ik heb er veel mee geexperimenteerd, en het komt er ongeveer op neer dat met de juiste "truuks" je meer dan driehonderd layers nog simultaan vloeiend kan rond laten bewegen, als je maar zorgt dat je de interval van de berekeningen los haalt van de werkelijke verplaatsing van de layers, en niet alles in een grote for loop achter elkaar laat updaten
Performance en platform is dan zo'n beetje gedefineerd

De view zou natuurlijk het tofste zijn als het in isometrisch perspectief was, maar een kaarsrecht grid is natuurlijk tien keer makkelijker (maar saaier), daar moeten we denk ik wat later over gaan nadenken, want op zich hoef je je misschien helemaal niet aan "grids" te houden, en doe je gewoon algehele box-collision met vrije movement, en maak je je graphics in isometrisch perspectief, dan ben je ook van het gezeur af.

Beehive staat idd nog op sourceforge es kijken of ik dat daar weg kan halen want dat is echt nix geworden daarlangs. CVS is ook een ramp om mee te werken
Ik wou beehive trouwens wel gaan gebruiken, zei het in een aangepaste vorm. Netscape support kan er allemaal uit e.d. maar een library is denk zeker in dit geval een must, al zal ik ook hiervoor dan echt eens docs moeten gaan schrijven of op zijn minst een quick reference oid.

Toch moeten we ons nu echt eerst op een verhaal en spelregels gaan richten, de code komt later wel

[Bosmonster]

Op donderdag 13 juni 2002 11:59 schreef Pelle het volgende:
Multiplayer lijkt me nog te lastig; tenminste, ik stel me erbij voor dat we eerst zorgen dat de speler zelf 2 tegenstanders aan kan sturen en dus tegen elkaar kan laten spelen. De lol daarvan is natuurlijk ver te zoeken, want je wint altijd, maar als dat eenmaal werkt kun je na gaan denken over hoe je die tegenstander gaat vervangen door een AI of een tegenstander ergens aan de andere kant van de wereld.

De vraag is: Wat is makkelijker?

Computer AI of Multiplayer

[Annie]

Op donderdag 13 juni 2002 09:34 schreef Blues het volgende:
/me vraagt zich af of hij de enige in het project is die zowel War- als Starcraft nooit heeft gespeeld.

* Annie zegt: shame, shame, a bloody shame

Op woensdag 12 juni 2002 23:50 schreef drm het volgende:

• Annie(geluidjes en beta-testing? )

Beta-testing wil ik dolgraag doen. En eigenlijk wil ik ook wel helpen met coden, maar weet van mezelf dat ik op dit moment tijd te weinig en maagzweren teveel heb en wil het project (als het al gaat lopen) niet nodeloos ophouden.
Geluid is niet m'n sterkste kant

Op donderdag 13 juni 2002 11:01 schreef Gordijnstok het volgende:
Dan blijven nog een hoop punten over

1) Performance
2) AI
3) Verhaal
4) Platform
5) Top-down view of met een lichte angle ?
6) Tegen de computer? Of multiplayer?
7) etc.

1. Ja graag
2. Denk dat dat 'simpel' moet worden opgezet in het begin, het moet hier iig niet op stuk gaan lopen (bijv. door te veel, te vroeg te willen, zoals Pelle al aangaf)
3. Dat moet niet al te moeilijk zijn, standaard "good guys - bad guys met een meningsverschil" verhaaltje.
4. Je bedoelt systeem eisen? Ik zou zelf kiezen voor een duidelijk afgebakend gebied en zeker niet willen dat het maar compatible moet zijn met "alle" browsers/OS-en. Het is een game en als je er eentje koopt in de winkel zal je ook moeten kijken of 'ie werkt. Bovendien maakt dat het coden makkelijker.
   Voorstel: W3C-DOM only (of toch nadruk op IE? is nu eenmaal grootste publiek)
5. starcraft style, dus graphics geven "schijn 3D". Ik weet alleen niet of dat problemen geeft voor de creatieve wonderen onder jullie (neem aan van niet) bij het maken van de images.
6. zie 2, tegen CPU dus
7. ongetwijfeld

Op donderdag 13 juni 2002 12:01 schreef Tizzwat het volgende:
Met PHP/ASP kun je imho zeker niet goed een multiplayer versie opzetten.
Tenzij er alleen sprake is van een scorebord o.i.d.

Kan wel, maar dan krijg je een soort turn-based principe. En da's nix imho.

[Bosmonster]

Op donderdag 13 juni 2002 12:14 schreef Annie het volgende:

[..]


Kan wel, maar dan krijg je een soort turn-based principe. En da's nix imho.

Dan is het ook geen RTS meer

[maartenba]

Multiplayer zou in principe kunnen door de DHTML (js) wat commando's te laten sturen naar een embedded Flash-movie, die dan alle servercommunicatie op zich neemt...

Ik wil trouwens wel meedoen aan de multiplayer-opties, heb in Flash en Perl (voor de server) een gamepje gemaakt...
(www.fightclub.be, en als je niet kan inloggen effe 2 secjes naar http://www.squirrel.be/paintball/srv.pl surfen, dan wordt de server aangezet...)

Dus als er beslist wordt om MP te gaan -> count me in

[Verwijderd]

Voor multiplayer kun je gebruik maken van XML sockets in Flash Ik heb hier nog een XML Socket server staan voor Flash die ik al eens heb moeten ontwikkelen in VB6.

Vervolgens ga je vanuit de Flash animatie de JS commando's geven

Zowiezo is het verstandig om eens te kijken naar de performance verschillen tussen VBScript en JScript onder MSIE6 Wellicht dat je deze samen kunt gaan gebruiken om tot de snelste oplossing te komen.

Wat wellicht ook leuk is, is om mega multiplayer te creeeren. Geef elke speler gewoon 1 tank en klaar Vervolgens als je met 50+ spelers bezig bent is het complete carnage

Is misschien ook wel het verstandigste om mee te beginnen. Basic acties van een unit Dus nog zonder bouwen etc..

[Woudloper]

Clay:
javascript kan ook met xml overweg da's wel IE only, maar ik koester toch niet de valse hoop dat dit op enig andere browser gaat werken dan IE, netscape 4 is sinds enkele dagen officieel 5 jaar oud en mozilla trekt het gewoon niet als je veel layers wil bewegen.

Mozilla kan ook al overweg met XML, zie het topic van Crisp over zijn GOT-Tracker, want daar had hij namelijk het verwerken van XML client-side aan de praat gekregen op beide browsers.

Maar net zoals andere zeggen, kunnen we beter voor 1 bepaalde omgeving kiezen... * Woudloper stelt voor om het te baseren op W3C-DOM, maar dan wel toegespitst op IE

Performance maak ik me op zich niet al te veel zorden over. Ik heb er veel mee geexperimenteerd, en het komt er ongeveer op neer dat met de juiste "truuks" je meer dan driehonderd layers nog simultaan vloeiend kan rond laten bewegen, als je maar zorgt dat je de interval van de berekeningen los haalt van de werkelijke verplaatsing van de layers, en niet alles in een grote for loop achter elkaar laat updaten
Performance en platform is dan zo'n beetje gedefineerd

Pelle had toch ooit een probleem met het schrijven naar meerdere layers/divs bij zijn PellePaint, hij kreeg toen een stack-overflow o.i.d.

De view zou natuurlijk het tofste zijn als het in isometrisch perspectief was, maar een kaarsrecht grid is natuurlijk tien keer makkelijker (maar saaier), daar moeten we denk ik wat later over gaan nadenken, want op zich hoef je je misschien helemaal niet aan "grids" te houden, en doe je gewoon algehele box-collision met vrije movement, en maak je je graphics in isometrisch perspectief, dan ben je ook van het gezeur af.

Wow een mond vol zeg

Ik denk dat we hiervoor wel het voorstel kunnen gaan volgen van Annie. Dus het aanzicht wat je ook hebt vanuit StarCraft...

Het zou natuurlijk ook grappig zijn als je zelf je instellingen kan doen. Dus ik wil deze view en dan mag jij met je eigen view gaan werken....

Toch moeten we ons nu echt eerst op een verhaal en spelregels gaan richten, de code komt later wel

Zoals Annie zegt een goede mensen/slechte mensen (aliens) lijkt mij wel een goed plan... Aangezien het StarCraft heet waarom zullen we het niet laten gaan over sterrenstelsels

[oh,when?]

ja wat wordt het nou? flash of lekker gewoon dhtml. kzou het persoonlijk veel meer een uitdaging vinden om het in dhtml only te proberen, multiplayer hoeft voor mij niet eens een optie te zijn. je kan wel leuk in halfgare flash-js-bridges gaan werken, maar dan kan je net zo goed helemaal in flash gaan werken. en om eerlijk te zijn wordt het dan voor mij geen uitdaging meer, ik werk dagelijks met flash / xml / java communicatie dingen.

maar goed. pathfinding. Hoeft ook niet zo heel ingewikkeld te zijn, denk alleen dat performancewise in dhtml echt slecht trekt. Zoek maar eens op Google op A* Algoritme. Tonnen met links, heb weleens zoiets in Flash gebouwd, eens kijken of ik de source op kan diggen.

Een goede link: http://www.cpcug.org/user/scifair/Preygel/Preygel.html

[Pelle]

Op donderdag 13 juni 2002 12:36 schreef Woudloper het volgende:
Pelle had toch ooit een probleem met het schrijven naar meerdere layers/divs bij zijn PellePaint, hij kreeg toen een stack-overflow o.i.d.

Dat lag niet aan de layers zelf, maar aan het feit dat JS niet zo goed om kon gaan met een recursieve functie die zichzelf 4 keer aanroept... dat gaat al snel uit de klauwen lopen bij een veld van 20 bij 20, en dan krijg je een stack-overflow. Heeft niks met layers te maken, als wel met de stack die voor JS blijkbaar niet zo hoog is.

[BtM909]

Damn...

* BtM909 zou heel graag mee willen doen met coden, geluidjes, en testen, maar heb totaal geen tijd. Ben nu te druk met andere zaken.....


Echt jammer, want dit zijn de leukere uitdagingen (alhoewel ik ook nooit StarCraft heb gespeeld).

Mochten jullie nog gaten hebben (denk het niet met zulke toppers ), dan kunnen jullie me altijd benaderen. Ik kan altijd nog mijn prioriteiten verleggen.


I'm gonna watch this topic.

[Verwijderd]

ik ben eventjes de Shortest Path Algoritme's aan het bekijken, maar persoonlijk vind ik het Manhatten algoritme er het mooist uitspringen, omdat je zo niet zoveel mogelijk hemelsbreed gaat rekenen, maar echt langs de randen van een plas water, etc.


Manhattan heuristic:


Dijkstra hemelsbreed:


A* gedeeltelijk heuristic:


Wat ik me alleen een beetje afvraag, als je 2 mogelijkheden hebt voor een path, met identiek aantal stappen, welke pad je het beste kunt kiezen. Dan kun je op zich alle huidige bewegingen in een array plaatsen en vergelijken. Zodra je een vijand op 1 van die 2 mogelijkheden tegenkomt kun je het andere pad pakken. Je wilt zoveel mogelijk de vijand ontwijken. Dit is natuurlijk weer anders als op allebij de mogelijke paden vijanden beweging hebben. Dan moet je ook nog eens gaan kijken naar het aantal vijandelijke eenheden op de paden, en zelfs eventueel de vuurkracht per eenheid.

Zo kan een tank makkelijk een een jeepje met een basic wapen aan Maar opgeteld, zijn 5 jeeps weer sterker als een tank.

Al met al een behoorlijke klus denk ik

[Verwijderd]

/me zal ook graag wel wat dingetjes voor zo'n project willen doen.
Al is het alleen maar code herschrijven, om het duidelijker te houden, en om te optimaliseren.

Het behoort IMHO wel een open-source project te blijven, wat niet alleen betekent dat de code te zien moet zijn (duh), maar ook nog te begrijpen.

Over de post van Gordijnstok hierboven: het is natuurlijk prachtig als je meerdere SP algoritmes houdt, en de AI te laten bepalen welke het meest succesvol is.

[Clay]

Het is extreem voorbarig , maar dit is een voorbeeldje van hoe je object overerving kan doen in JS, vooral dat super.call(meuk) is erg leuk

de Unit erft van Actor, en de Marine erft van Unit. een Tank zou ook van Unit erven, terwijl een gebouw bijvoorbeeld weer van Actor erft oid, 't is maar een idee, maar dit lijkt me een erg generiek systeem kunnen worden zo.

code:

var iActorUpdateDelay = 40;
document.actors = [];

//Actor object
// ----------------------------------------------
function Actor(x,y,w,h) {   
    this.x = x;
    this.y = y;
    this.w = w;
    this.h = h;

    var pos = document.actors.length;       
    this.id = "Actor"+pos;
    document.actors[pos] = this;
    document.actors[this.id] = this;    
}

    // object method "build", creeert bijvoorbeeld de sprite
    Actor.prototype.build = function() {        
        this.sprite = "...";

        if(this.update)
            this.thread = setInterval('document.actors["'
                +this.id+'"].update()', iActorUpdateDelay);
    }


// Unit object
// ----------------------------------------------
function Unit(x,y,w,h) {
    this.time = 0;  
    
    // roept superclass (Actor) aan voor properties
    Actor.call(this, [x,y,w,h]);    
}

    // overerving van Actor
    Unit.prototype = new Actor();
    
    // methode "update", wordt vanuit superclass aangeroepen
    Unit.prototype.update = function() {
        this.time ++;
        window.status = this.time;
    }


// Marine object
// ----------------------------------------------
function Marine(x,y,w,h,owner) {
    this.owner = owner;
    
    // roept superclas (Unit) aan voor properties
    Unit.call(this, [x,y,w,h]);
    
    // build() van Actor, update() van Unit
    this.build();
}

    // overerving van Unit
    Marine.prototype = new Unit();
    // Mag ook een eigen update() defineren
    // Marine.prototype.update = function(){}
    

// test, check je window.status
// ----------------------------------------------
new Marine(10,10,100,100, 'player1');

[crisp]

Op donderdag 13 juni 2002 12:36 schreef Woudloper het volgende:

[..]

Mozilla kan ook al overweg met XML, zie het topic van Crisp over zijn GOT-Tracker, want daar had hij namelijk het verwerken van XML client-side aan de praat gekregen op beide browsers.

Maar net zoals andere zeggen, kunnen we beter voor 1 bepaalde omgeving kiezen... * Woudloper stelt voor om het te baseren op W3C-DOM, maar dan wel toegespitst op IE
[..]

Inderdaad! Het heeft me echter wel een hele avond gekost om het in Mozilla mogelijk te maken een XML vanaf een ander domein binnen te trekken; de client-site security is erg strict afgesteld bij Mozilla, en hier is helaas weinig over te vinden op het web (zou ik dan de eerste zijn die het gelukt is? )
De GoT Tracker had ik al volledig DOM in elkaar geprogged, waardoor het zonder al te veel aanpassingen verder zo in Mozilla draaide (wel wat kleine wijzigingen mbt afvragen cursorpositie en window groottes, maar dat was het wel zo'n beetje).
Check de source er maar eens op na, en dan met name de xmlparser.js (aangepaste versie van webFX). Client-side XML support is trouwens in Mozilla native, terwijl dat bij MS via een activeX object moet...

O ja, ik wil ook best meewerken, maar ligt er een beetje aan wat. Als er wat vastomlijnde taken zijn, dan kan ik wel zeggen wat ik wel of niet aankan; ben tenslotte nog maar een amateur wat scripten betreft, en OO is/was al helemaal nieuw voor me...

[Verwijderd]

Op donderdag 13 juni 2002 07:42 schreef Karp het volgende:
Ik wil helpen!


maar ik kannie scripten....

Hier hetzelfde probleem

Schrijf mij ook maar in voor BETA testing?
en als ik iets kan helpen met photoshoppen/HTML rotzooi, dan roep me maar
[sub]^{*geen DHTML held zijnd*[/sub]}

[Pelle]

Had het er net nog even over met drm; hij gaat straks nog wel even een mooie samenvatting schrijven van wat er hier vandaag allemaal geroepen is, maar ik ga in ieder geval alvast verklappen dat het ons allebei wel handig leek om simpel te beginnen, en steeds een stap verder te gaan.

Creeer eerst een map, met gedeeltes waar te lopen is en gedeeltes waar niet te lopen is. Zorg voor een unit, die kan bewegen. Geef zo'n unit een destination point en laat 'm daarheen lopen. Geef een unit een objective om te vernietigen. Maak een map met meerdere hoogtes erin. Maak 2 units die elkaar moeten vernietigen. Maa meerdere units met hetzelfde objective. Maak meerdere units met andere karakteristieken met een tegenstrijdig objective. Enzovoorts, enzovoorts.
Steeds een stapje verder; een verhaallijn of graphics zijn nog niet interessant in dit stadium.. het gaat met name om hoe definieer ik een map, een unit, de behavior van die unit, de properties van een unit en z'n objective(s).
Lijkt me al lastig genoeg om mee te beginnen in ieder geval

[drm]

Pelle:
Had het er net nog even over met drm; hij gaat straks nog wel even een mooie samenvatting schrijven van wat er hier vandaag allemaal geroepen is

* drm vindt het tijd om te pitten en zegt:
Pelle, bedankt voor de verwoording

morgen ga ik nog wel wat nuttigere replies doen, maar nu ben ik daar te brak voor

[Pelle]

Op vrijdag 14 juni 2002 01:52 schreef drm het volgende:
morgen ga ik nog wel wat nuttigere replies doen, maar nu ben ik daar te brak voor

Tsk.. jij kan ook nergens tegen.. heeft de hele dag vrij, doet niks, drinkt een paar biertjes en stort meteen in

_{* Pelle is ook aardig brak overigens.. lang leve thuis/telewerken eens in de zoveel tijd}

[Verwijderd]

Alleen al het definieren van een sprite wordt een helse klus. Je zult zowiezo op pixel niveau de sprite moeten definieren omdat je exotische vormen qua afbeeldingen wilt gebruiken, die alles behalve rechthoekig, vierkant zijn

Kortom, je moet per afbeelding exact de boundaries gaan opgeven. Dat in combinatie met de gigantische sprite die gelijke staat aan client resolutie kan voor een gigantische performance drop zorgen.

[Woudloper]

Gordijnstok:
Alleen al het definieren van een sprite wordt een helse klus. Je zult zowiezo op pixel niveau de sprite moeten definieren omdat je exotische vormen qua afbeeldingen wilt gebruiken, die alles behalve rechthoekig, vierkant zijn

We moeten gewoon echt bij het begin beginnen en niet te hard van stapel lopen Zelf dacht ik aan een volgend stappenplan....

• Idee, wat gaan we doen... <-- is er dus al
• Het verhaal (kan gedeeltelijk los staan van ontwikkeling.
• Beginnen met basis library (evt. Beehive) voor het programmeren...
• Opzetten van de basis elementen (map, sprite, etc..)
• Uitbouwen van de basis elementen...
• etc.. etc...

Kortom, je moet per afbeelding exact de boundaries gaan opgeven. Dat in combinatie met de gigantische sprite die gelijke staat aan client resolutie kan voor een gigantische performance drop zorgen.

Helemaal gelijk, maar first things first...

[Verwijderd]

Op vrijdag 14 juni 2002 08:48 schreef Woudloper het volgende:
Helemaal gelijk, maar first things first...

Maar dat zijn juist de eerste dingen Het opzetten van een basis "werkblad" waarop de rest komt

[Annie]

Op vrijdag 14 juni 2002 08:35 schreef Gordijnstok het volgende:
Alleen al het definieren van een sprite wordt een helse klus. Je zult zowiezo op pixel niveau de sprite moeten definieren omdat je exotische vormen qua afbeeldingen wilt gebruiken, die alles behalve rechthoekig, vierkant zijn

Nee joh, de grenzen van zo'n sprite mogen best vierkant/rechthoekig zijn. Als je daar een beetje rekening mee houdt in het design van de units/buildings dan zul je dat niet eens merken.
Evt. kan je later alsnog extra boundary-properties voor het object definieren en daarop laten reageren (als dat niet teveel performance kost tenminste).

[Bosmonster]

Op vrijdag 14 juni 2002 09:31 schreef Annie het volgende:

[..]

Nee joh, de grenzen van zo'n sprite mogen best vierkant/rechthoekig zijn. Als je daar een beetje rekening mee houdt in het design van de units/buildings dan zul je dat niet eens merken.
Evt. kan je later alsnog extra boundary-properties voor het object definieren en daarop laten reageren (als dat niet teveel performance kost tenminste).

Dat vierkante maakt inderdaad niks uit.. Zeker ni een eerste versie zal je imho tile-based te werk willen gaan. Die hoogteverschillen waar Pelle het over heeftl ijken me ook toekomstmuziek

Laten we eerst eens een map maken en units die kunnen bewegen middels pathfinding. Daar zijn we al wel ff zoet mee denk ik

[drm]

Clay:
Het is extreem voorbarig , maar dit is een voorbeeldje van hoe je object overerving kan doen in JS, vooral dat super.call(meuk) is erg leuk

Ik denk zelfs dat je binnen zo'n spel niet onder OO uitkomt. Zeker in JS niet. En wat is een OO model zonder overerving?

Pelle:
Tsk.. jij kan ook nergens tegen.. heeft de hele dag vrij, doet niks, drinkt een paar biertjes en stort meteen in

Thread is te kort om te samenvatten. Als je wilt weten wat er staat, neem je maar de moeite 't even te lezen

Maar goed, bij deze een poging een wat nuttigere reply te doen...

Gister was Pelle bij mij thuis, en hebben we 't er even over gehad, en we kwamen tot de volgende conclusie:

De eerste stappen die we moeten zien te bereiken zijn:
• We hebben een map,
• We hebben een unit,
• unit weet hoe hij van a naar b moet komen.

Als we dat weer een stukje uitsplitsen, kom je er basically op uit: hoe gaan we een map definieren? D'r is hier en daar al wat geroepen over sprites, e.d., dus een beetje kennis is er wel

Ik zou iedereen willen vragen alle wilde ideeen over multiplayer op internet eventjes achterwege te laten, en dat we het brainstormen even binnen dit doel beperkt houden.

Step-by-step...

Daarnaast denk ik, dat als er een goed model neergezet wordt voor units, (een aantal properties zoals snelheid, intelligentie?, aanvals- en verdegigingskracht, etc...), het verhaal niet eens belangrijk is. Als mensen er ideeen over hebben, da's leuk, maar dat is zeker niet het belangrijkste. imho

dus:

Wie is vrijwilliger voor het verzinnen van een map, waarin we een pathfinding algoritme kunnen implementeren?
Even binnen dat kader brainstormen

_edit:
Bosmonster: gmta

[Bosmonster]

Op vrijdag 14 juni 2002 09:41 schreef drm het volgende:

[..]

Wie is vrijwilliger voor het verzinnen van een map, waarin we een pathfinding algoritme kunnen implementeren?
Even binnen dat kader brainstormen

Heb er ff geen tijd voor vandaag, maar het lijkt me verstandig deze op te bouwen uit tiles. Dus eerst een tile-object definieren met eigenschappen als X, Y, img, accessability. Op die manier kun je simpelweg kijken of je over een tile heen kunt ja nee in de map en heb je geen losse 1/0-map nodig.

_edit:
Bosmonster: gmta

[drm]

Even nog over de hoogte:

Dit is toch redelijk eenvoudig te realiseren op de tiles. Ik weet niet hoe het dan met pathfinding zit (daar mag iemand anders wat over roepen), maar je kunt voor een tile toch opgeven of hij vanaf het noorden, oosten, westen of zuiden accessible is?

Als je een 'accessible' waarde dan niet alleen 'true' of 'false' geeft, maar gewoon een hoogte verschil, waarbij een verschil tussen tile_van en tile_naar niet meer dan (-)2 mag zijn, dan heb je dat toch te pakken?

Daarnaast hoeft de tile zelf niet te weten op wat voor positie hij zit. Dat is een laagje hoger (2 dimensionale array 'map', gok ik)

Verder hoeft een tile enkel een grafische representatie te hebben. Toch?

[r0bert]

* r0bert houdt zich nog wel even op de achtergrond, want is druk met wat andere projectjes.. zal binnenkort wel inhaken

[Verwijderd]

/me had al overactief een mammoth tank uit C&C Tiberian Dawn geripped om te testen

Met dank aan Tom voor HTML enablen

<table border="0" cellspacing="0" cellpadding="0" width="100%" height="150" background="http://beheer.smash.net/micha/grass.gif"><tr><td align="center"></td>
</tr>
</table>

[Bosmonster]

Op vrijdag 14 juni 2002 10:14 schreef drm het volgende:
Even nog over de hoogte:

Dit is toch redelijk eenvoudig te realiseren op de tiles. Ik weet niet hoe het dan met pathfinding zit (daar mag iemand anders wat over roepen), maar je kunt voor een tile toch opgeven of hij vanaf het noorden, oosten, westen of zuiden accessible is?

Als je een 'accessible' waarde dan niet alleen 'true' of 'false' geeft, maar gewoon een hoogte verschil, waarbij een verschil tussen tile_van en tile_naar niet meer dan (-)2 mag zijn, dan heb je dat toch te pakken?

Daarnaast hoeft de tile zelf niet te weten op wat voor positie hij zit. Dat is een laagje hoger (2 dimensionale array 'map', gok ik)

Verder hoeft een tile enkel een grafische representatie te hebben. Toch?

True.. das een goed idee.. X/Y is redelijk nutteloos in de tile. grafische represenatie zie ik gewoon als img, GIF of JPG of PNG (PNG lijkt me ok, alleen heeft IE daar nu juist weer beperkingen in, maar das ander verhaal weer ).

Accessibility N/S/E/W is cool, maar waarschijnlijk kan je het dan niet meer kwijt in 1 platte property, aangezien je ook meerdere mogelijkheden kan hebben, zoals met een brug oid.

Hoogteverschil in de kaart is in principe nog wel te doen, alleen als je dat ook wil viualiseren ni de units is dat lastig.. en anders ziet het er nogal vaag uit denk ik

[Verwijderd]

hum... impressive project...

ik denk however dat het gaat staan of vallen met de snelheid van het zoekalgoritme...

heb een oud (1997) stuk source opgedoken die jullie misschien wat verder helpt. Het is in C , dus het converten zal niet moeilijk zijn.... Er worden wat functies uit een andere lib gebruikt om shit op te tekenen en te laden enzo.. maar dat moet er dus toch allemaal uit.

Verder gaat het hier dus om het A* algo. Waarbij ik de (en dit is de key voor een snelle engine) hele SEARCHSPACE van te voren alloceer! das dus heel fijn, want dan hoef je alleen maar 'vlaggetjes' aan en uit te zetten om aan te geven of je iets al hebt bezocht of niet, etc...

nah, hier komt ie dus, remember this is RAW unedited code, straight from the archives

first up c. file.. 'system' functions
apath.c

Nou, hoop dat jullie er wat aan hebben.
Ben ofcoz altijd bereikbaar voor commentaar.

Gerbert

[Bosmonster]

Op vrijdag 14 juni 2002 10:41 schreef Fetishcoder het volgende:
hum... impressive project...

ik denk however dat het gaat staan of vallen met de snelheid van het zoekalgoritme...

heb een oud (1997) stuk source opgedoken die jullie misschien wat verder helpt. Het is in C , dus het converten zal niet moeilijk zijn.... Er worden wat functies uit een andere lib gebruikt om shit op te tekenen en te laden enzo.. maar dat moet er dus toch allemaal uit.

Verder gaat het hier dus om het A* algo. Waarbij ik de (en dit is de key voor een snelle engine) hele SEARCHSPACE van te voren alloceer! das dus heel fijn, want dan hoef je alleen maar 'vlaggetjes' aan en uit te zetten om aan te geven of je iets al hebt bezocht of niet, etc...

nah, hier komt ie dus, remember this is RAW unedited code, straight from the archives

[lap code]

Nou, hoop dat jullie er wat aan hebben.
Ben ofcoz altijd bereikbaar voor commentaar.

Gerbert

Bedankt hoor

[drm]

Gordijnstok:
* drm had al overactief een mammoth tank uit C&C Tiberian Dawn geripped om te testen
[snip]

(misschien heeft iemand nog zin om een mooie te tekenen? )

Lijkt me idd best een aardig unitje om mee te klooien.

Bosmonster:
True.. das een goed idee.. X/Y is redelijk nutteloos in de tile. grafische represenatie zie ik gewoon als img, GIF of JPG of PNG (PNG lijkt me ok, alleen heeft IE daar nu juist weer beperkingen in, maar das ander verhaal weer ).

Grafische representatie komt nog wel, imo...

Accessibility N/S/E/W is cool, maar waarschijnlijk kan je het dan niet meer kwijt in 1 platte property, aangezien je ook meerdere mogelijkheden kan hebben, zoals met een brug oid.

Een brug bestaat toch ook uit tiles? Je moet alleen geen bruggetjes willen maken die < 1 tile zijn

Hoogteverschil in de kaart is in principe nog wel te doen, alleen als je dat ook wil viualiseren ni de units is dat lastig.. en anders ziet het er nogal vaag uit denk ik

goed punt, visualisatie van hoogten... ideeen?

[Willem]

Op vrijdag 14 juni 2002 10:41 copy-peeste Fetishcoder een stuk C:

Regels code verwijderd wegens onleesbaarheid pagina...
Mail is gestuurd.

[Clay]

Op vrijdag 14 juni 2002 10:14 schreef drm het volgende:
Even nog over de hoogte:

Dit is toch redelijk eenvoudig te realiseren op de tiles. Ik weet niet hoe het dan met pathfinding zit (daar mag iemand anders wat over roepen), maar je kunt voor een tile toch opgeven of hij vanaf het noorden, oosten, westen of zuiden accessible is?

Als je een 'accessible' waarde dan niet alleen 'true' of 'false' geeft, maar gewoon een hoogte verschil, waarbij een verschil tussen tile_van en tile_naar niet meer dan (-)2 mag zijn, dan heb je dat toch te pakken?

Daarnaast hoeft de tile zelf niet te weten op wat voor positie hij zit. Dat is een laagje hoger (2 dimensionale array 'map', gok ik)

Verder hoeft een tile enkel een grafische representatie te hebben. Toch?

Precies en laat ik dat nou net ook geillustreerd willen posten


Op deze manier heb ik ooit pacman gemaakt. Een veld "weet" of je wel of niet naar rechts, links, boven of onder kan, en dus is de "collision berekening" onafhankelijk van de grootte van het speelveld, als is het 1000 bij 1000, nadeel is wel dat je aan een wat simpel grid vast zit, al hoef je het natuurlijk grafisch maar beperkt aan het werkelijke grid te koppelen.


Deze is iets anders. Hierbij heb je nog wel een grid, maar dat is volledig los van de graphics. Een grid "vak" zou redelijk groot kunnen zijn, omdat het gridveld nu niet bijhoudt of je naar links of rechts etc kan. Het heeft nu een lijst met blokken die in zijn eigen grid oppervlak vallen waar een unit tegenaan zou botsen. Zo houd je dus geen rekening met collision aan de andere kant van het speelveld, en dat is goed 1 puntje is wel dat je tegelijk ik maximaal 4 gridvlakken kan zitten als unit, dus je bent maximaal de blokken aan het bekijken van 4 gridvlakken gecombineerd. Deze manier heb ik in een simpelere versie in operation043 toegepast.


Dit is de bruutste, en ik denk ook een te brute. net als de 2e kan je voor de performance een grid bijhouden met collision blokken, maar zodra je "in" zo'n blok komt gaat er een 2e berekening lopen die collision voor veelhoeken toe kan passen. Dat is op zich redelijk simpel; als je in een veelhoek zit (zonder uitstulpsels) zijn alle hoeken bij elkaar opgeteld 360, en daarbuiten 0. Alleen moet je er een flinke bak gonio tegenaan gooien om met enkel wat x en y coordinaten dit allemaal te berekenen.
Dit heb ik gebruikt in een racespelletje, maar dat ging me eigenlijk wat te ver

Dit zijn natuurlijk maar 3 manieren, en er zullen er nog veel meer zijn. De vraag is ook welke manier het makkelijkste is te combineren met een pathfinder, en die laatste lijkt me dan al meteen afvallen. Zelf zou ik het liefst de 2e toepassen. Grids die je ook grafisch koppelt zijn toch wat beperkend.

[drm]

Het subtiele verschil tussen de 1^e en de 2^e is mij niet helemaal duidelijk...

Als ik het goed begrijp bedoel je basically dit:

Bij de 1e houdt de map bij of er collision optreedt,
bij de 2e houdt de unit dit bij.

klopt dat?

[Juup]

Hee gaaf project dit. Kun je in javascript sockets openen om data van/naar een server te sturen?

Algemeen:

Ik zou als ik jullie was HEEL simpel beginnen met een VLIEGTUIGJE (Wraith). Die hoeft niet om obstakels heen

Neem een simpele map en doe ALLES zoals in starcraft (dan hoef je niets te kiezen/ruzien). K.I.S.S. (Keep It Simple, Stupid!)

Dit kon wel eens de eerste starcraft worden die op een hogere res dan 640x480 gespeeld kan worden! lol

[Verwijderd]

Waar ik zelf in eerste instantie aan dacht, was om een sprite te maken per pixel adhv de resolutie. Zo heb je de hoogst mogelijke precisie qua positionering.

Deze precisie kun je vervolgens bijwerken met een factor*sprite entry. Hoe hoger de factor hoe hoger de performance, en hoe lager de precisie van een unit op de map.

Je kunt vervolgens per obstacle in de map coordinaten bijhouden, net zoals in de map editors van Westwood werd gedaan. Een obstacle zoals een coastline bestaat dus uit meerdere obstacles wat als voordeel heeft dat je afbeeldingen kunt hergebruiken om zo performance omhoog te schroeven.

De obstacles vergelijk je bij initialiseren met de gerenderde sprite van je scherminhoud. Zo ga je dus alleen obstacles definieren ipv een algehele map.

[DeFeCt]

* DeFeCt meldt zich aan als alpha tester

[drm]

Jaaap:
Hee gaaf project dit. Kun je in javascript sockets openen om data van/naar een server te sturen?

de serverside is nog lang niet aan de orde, laat staan multiplayeren, etc... RTFT

Ik zou als ik jullie was HEEL simpel beginnen met een VLIEGTUIGJE (Wraith). Die hoeft niet om obstakels heen

Daar is dus niets aan. Want dan is het een kwestie van richtingscoefficient berekenen en vliegen maar.

Neem een simpele map en doe ALLES zoals in starcraft (dan hoef je niets te kiezen/ruzien). K.I.S.S. (Keep It Simple, Stupid!)

D'r wordt niet geruzied

Dit kon wel eens de eerste starcraft worden die op een hogere res dan 640x480 gespeeld kan worden! lol

Nog niet eens aan gedacht idd


_edit:

Gordijnstok:
Waar ik zelf in eerste instantie aan dacht, was om een sprite te maken per pixel adhv de resolutie. Zo heb je de hoogst mogelijke precisie qua positionering.

Deze precisie kun je vervolgens bijwerken met een factor*sprite entry. Hoe hoger de factor hoe hoger de performance, en hoe lager de precisie van een unit op de map.

Je kunt vervolgens per obstacle in de map coordinaten bijhouden, net zoals in de map editors van Westwood werd gedaan. Een obstacle zoals een coastline bestaat dus uit meerdere obstacles wat als voordeel heeft dat je afbeeldingen kunt hergebruiken om zo performance omhoog te schroeven.

De obstacles vergelijk je bij initialiseren met de gerenderde sprite van je scherminhoud. Zo ga je dus alleen obstacles definieren ipv een algehele map.

Wat je dan dus in feite doet, is de map downscalen, en de map bestaat dan uit tiles, die in feite ook weer maps zijn?

_edit2:
wordt redelijk lastig met hoogteverschillen, denk ik...

[oh,when?]

* oh,when? wil nog ff het volgende kwijt.

We lopen een beetje achter op onze Flash collega's waar tile-based games al veel eerder 'hip' waren

Kunnen we gelukkig wel van profiteren, aangezien core Actionscript niet veel verschilt van Ecmascript. Zo zijn er al veel tutorials te vinden, over hoe je tile-based mappings makkelijk kunt maken. Idd, met een simpele 2d-array. Grafische representaties zijn in dit stadium nog niet erg interesant ofcorz.

Vraag me nu wel af of we isobased of gewoon tile-based gaan werken. Enige verschil is dat je in isobased stiekem 2^{1/2 D} gaat werken en tile-based werk je gewoon 2^2d, viewpoint recht op de map. collision-detection is ook iets makkelijker te proggen.

btw:

About Amoeba RPG
The Amoeba RPG project is a Mozilla-based game engine which will allow anyone to create classic "super nintendo" or "early final fantasy" - style games. These are basically top-down tile-based adventure and role-playing games. Mozilla is uniquely qualified to be the "engine" behind this - since it already includes the facilities for displaying images, playing sounds, network connectivity , custom UI, and much more!

[..]

These are lofty goals, but with Mozilla being so powerful, and XML being the language of choice, and with javascript already available as a scripting language - I'm sure I can succeed in this. And a great side effect of this whole thing will be that finally game builders can start developing games in a cross-platform way - plus I want to encourage other gaming systems to help to create an XML-based standard for classic RPG games - this way other game systems could read/write/edit games using the same format. Plus all the code will be released under the MPL (Mozilla Public License) so others can take this code and write their own game engines. It's my hope that with your help, we can create a really kickass engine!

http://amoeba.mozdev.org/

[Clay]

Op vrijdag 14 juni 2002 11:06 schreef drm het volgende:
Het subtiele verschil tussen de 1^e en de 2^e is mij niet helemaal duidelijk...

Als ik het goed begrijp bedoel je basically dit:

Bij de 1e houdt de map bij of er collision optreedt,
bij de 2e houdt de unit dit bij.

klopt dat?

De unit vraagt in alletwee de gevallen aan de map/game of er collision optreedt, het verschil is dat bij de 1e een gridvlak ook zelf een collision blok is (en je dus beperkt bent tot vierkante collision blokken), en bij de 2e is het een soort container die informatie bevat over (onafhankelijke rechthoeken) collision blokken in de directe omgeving, namelijk binnen het eigen vak. Het grid zelf vertegenwoordigt dan ook geen graphics meer, dat doen de collision blokken zelf.

Gordijnstok
Waar ik zelf in eerste instantie aan dacht, was om een sprite te maken per pixel adhv de resolutie. Zo heb je de hoogst mogelijke precisie qua positionering.

Deze precisie kun je vervolgens bijwerken met een factor*sprite entry. Hoe hoger de factor hoe hoger de performance, en hoe lager de precisie van een unit op de map.

Je kunt vervolgens per obstacle in de map coordinaten bijhouden, net zoals in de map editors van Westwood werd gedaan. Een obstacle zoals een coastline bestaat dus uit meerdere obstacles wat als voordeel heeft dat je afbeeldingen kunt hergebruiken om zo performance omhoog te schroeven.

De obstacles vergelijk je bij initialiseren met de gerenderde sprite van je scherminhoud. Zo ga je dus alleen obstacles definieren ipv een algehele map.

Hier snap ik niets van sorry. maar je kan met dhtml geen pixels tekenen (toch? ) Jah, layers van 1x1, maar dat lijkt me niet slim.

[Bosmonster]

Op vrijdag 14 juni 2002 11:33 schreef Clay het volgende:

[..]

Hier snap ik niets van sorry. maar je kan met dhtml geen pixels tekenen (toch? ) Jah, layers van 1x1, maar dat lijkt me niet slim.

offtopic:
Dat wilde ik nog wel een keer doen.. gewoon een schermpje opbouwen uit 1x1 layers en middels kleurveranderingen animaties/spellen maken.

waarschijlijk zit je dan wel beperkt aan een erg klein schermpje (200/150 ofzo ) Maar je kan wel gelijk veel en veel meer... Met beetje inzoomen, maak je de layers gewoon 2x2.. is je schermpje ook groter

[Verwijderd]

Op vrijdag 14 juni 2002 11:19 schreef drm het volgende:
Wat je dan dus in feite doet, is de map downscalen, en de map bestaat dan uit tiles, die in feite ook weer maps zijn?

wordt redelijk lastig met hoogteverschillen, denk ik...

Dat klopt, aangezien ik eigenlijk er al van uit ga, dat hoogteverschillen nogal out of the question zijn momenteel. Dat wordt allemaal zo'n ingewikkeld verhaal. Alsof het allemaal al niet ingewikkeld genoeg is

[oh,when?]

Op vrijdag 14 juni 2002 11:12 schreef Gordijnstok iets begrijpelijk maar niet realischtisch:
Waar ik zelf in eerste instantie aan dacht, was om een sprite te maken per pixel adhv de resolutie. Zo heb je de hoogst mogelijke precisie qua positionering.algehele map.

Helaas werken we niet in C, maar gewoon in Javascript. spritebased position en moving / collision detection is gewoon niet realistisch. gewoon lekker in tiles gaan werken, simpel, makkelijk, neemt weinig geheugen in etc.

[Verwijderd]

Op vrijdag 14 juni 2002 11:33 schreef Clay het volgende:
Hier snap ik niets van sorry. maar je kan met dhtml geen pixels tekenen (toch? ) Jah, layers van 1x1, maar dat lijkt me niet slim.

Nee maar je kunt wel een boolean variabele zetten Het hoeft niet zichtbaar te zijn, het is alleen voor de scripting handig te weten waar ik wel en waar ik niet mag komen op de map.

Bij een resolutie van 640x480 krijg je dus een 2 dimensionale array, met een lengte van 640 en een diepte van 480.

Vervolgens worden deze bij initialisatie op false geflagged. Vervolgens wordt de map opgebouwd, en ga je per obstacle de flags op true zetten. Dan weet de scripting dat op dat punt hij niet mag komen.

Wat het nadeel hiervan is, is dat je array gigantisch groot wordt en ik weet niet hoe JS daarmee omgaat qua snelheid. Tevens moet je behoorlijk wat wiskundig rekenwerk verrichten om bij initialisatie de obstacles te definieren in flags op de basis sprite. Ik zat er zelf aan te denken om per afbeelding.gif een afbeelding.txt bij te houden. Serverside kun je deze vervolgens outputten in je JS code. In die afbeelding.txt staat dan een sprite voor alleen het obstacle.

Wat je ook kunt doen is werken vanuit een map maker. Daarvoor heeft Pelle al PellePaint gemaakt.

Je gebruikt dan als 1ste laag de grafische map, als 1 afbeelding. Als 2de laag leg je er een raster overheen welke je vervolgens via de Pellepaint manier kunt inkleuren. Op die manier ga je dus in de 2de laag aangeven wat de sprite voor de 1ste laag moet zijn.

[Bosmonster]

Array's zijn een van die dingen die in JS aardig snel zijn.. Ik heb er is een testje mee gedaan.. (al ging die niet over Array's )

http://bosmonster.b2f.nl/test.html

(is vergeljiking tussen look-up speeds in document.all, getElementById en een eigen Array met de objecten)

[Clay]

Op vrijdag 14 juni 2002 11:46 schreef Gordijnstok het volgende:

[..]

Nee maar je kunt wel een boolean variabele zetten Het hoeft niet zichtbaar te zijn, het is alleen voor de scripting handig te weten waar ik wel en waar ik niet mag komen op de map.

Bij een resolutie van 640x480 krijg je dus een 2 dimensionale array, met een lengte van 640 en een diepte van 480.

Vervolgens worden deze bij initialisatie op false geflagged. Vervolgens wordt de map opgebouwd, en ga je per obstacle de flags op true zetten. Dan weet de scripting dat op dat punt hij niet mag komen.

Wat het nadeel hiervan is, is dat je array gigantisch groot wordt en ik weet niet hoe JS daarmee omgaat qua snelheid. Tevens moet je behoorlijk wat wiskundig rekenwerk verrichten om bij initialisatie de obstacles te definieren in flags op de basis sprite. Ik zat er zelf aan te denken om per afbeelding.gif een afbeelding.txt bij te houden. Serverside kun je deze vervolgens outputten in je JS code. In die afbeelding.txt staat dan een sprite voor alleen het obstacle.

In feite is dat een vorm van de grid die zelf weet of je daarvandaan naar links/rechts/etc kan dus, maar dan pixelprecies, en kan je dus ook schuine dingen laten "colliden". De vraag is idd hoe soepel dit uiteindelijk kan worden, en ook hoeveel data je het geheigen in moet stauen Het is denk ik wel te doen, al moet je het speelveld wel in regio opdelen, zodat je per "zone" een collision array per pixel hebt, en niet in een megagrote brij hoeft te zoeken.
Snap ik um zo goed?

Wat je ook kunt doen is werken vanuit een map maker. Daarvoor heeft Pelle al PellePaint gemaakt.

Je gebruikt dan als 1ste laag de grafische map, als 1 afbeelding. Als 2de laag leg je er een raster overheen welke je vervolgens via de Pellepaint manier kunt inkleuren. Op die manier ga je dus in de 2de laag aangeven wat de sprite voor de 1ste laag moet zijn.

Een map maker zou zowiezo erg handig zijn zowiezo zal er uiteindelijk een bepaalde format uitrollen die alle aspecten van een level defineert, tiles of "pre-rendered" level delen, of een combinatie. Start locations, start units, etc.

[Juup]

Screenshots van starcraft:

<font style="color:#0000ff">Op verzoek van topicstarter weggehaald, screenshots van SC doen niet ter zake.</font>

[drm]

* drm is voorlopig tegen serversided zaken.

ik vind dat het zaakje offline moet kunnen draaien, zolang je tegen een pc speelt (hoe ver dat dan ook nog voor ons mag liggen)

zeker initialisatie van het spel moet gewoon door JS only gebeuren, imo

offehh, zie ik dan dingen over het hoofd?

[Bosmonster]

Ow ik moet nog iets toegeven:

Ik heb nooit StarCraft gespeeld!

Maar heb wel alle C&C versies en enkele andere clones tot op het bot afgekloven..

[Verwijderd]

Ik zou geen collision detection toepassen, maar enkel 'bullet/explosion'-collisions. Die zijn veel belangrijker.

[drm]

Bosmonster:
Ik heb nooit StarCraft gespeeld!

Je mist wat, honestly
^</offtopic>

[Verwijderd]

Ok. dan maar ff een link naar de files:

www.singularit.com/files/APATH.C
www.singularit.com/files/APATH.H

check it out...

[drm]

Fetishcoder:
Ok. dan maar ff een link naar de files:

www.singularit.com/files/APATH.C
www.singularit.com/files/APATH.H

check it out...

thnx absolutely handig

[Verwijderd]

/me heeft het voor mekaar gekregen zijn browser over de zeik te helpen

Ik dacht "ff kijken hoe snel JS een sprite van 640x480 mogelijkheden kan maken"

code:

<script type="text/javascript">
function init(){
MySprite = new Array
SetSprite();
}

function SetSprite(){
    for (var i=0; i <= 480; i++){
        for(var j=0; j <= 640; j++){
            MySprite.push(0,0)
        }
    }
    DrawSprites();
}

function DrawSprites(){
    for (var i=0; i <= 480; i++){
        for(var j=0; j <= 640; j++){
            document.write(MySprite[i,j])
        }
    document.write("<br>")
    }
}

init();
</script>

Als het nou C zou zijn geweest

[drm]

Gordijnstok: [snip]

output:

code:

00000000000000000000000000000

en dat dan heel vaak en met enige regelmaat breaks ertussen

maar goed, 640 x 480 map array is imo sowieso not done.

[Verwijderd]

Op zich gaat het wel snel. Alleen de initialisatie duurt een paar seconden. Maar daarna kun je reterap een 1 of een 0 zetten en opvragen

Daarna zou je dan de objecten in die Array op 1 kunnen zetten afhankelijk van de top en left posities

Het outputten koste mijn browser zijn geduld

[Clay]

Maar het speelveld zal eerder duizend(en) bij duizend(en) pixels zijn dan 640 480, en dan heb je al een miljoen arrayposities. Het lijkt mij eigenlijk onhaalbaar om dat zo te doen.

iets, anders;
Ik heb even een snel & simpel schermscroll testje gemaakt. 30 bij 30 "tiles" in een table met een tile van 100 bij 100 pixels, in een scherm van 800x600.

scrolltest

Dit loopt hier op mijn werk (p800 oid) prima. 40 bij 40 gaat schokken, en nog meer zorg voor zo'n "dit script trekt te veel, wil je nokken?" melding.

[Bosmonster]

Hmm loopt hier ook ok op p3-800. Maar een tile van 100 bij 100 is wel erg groot!

[Bluestorm]

Werkt hier ook goed op (Athlon 1 Ghz) Tenminste... toen ik door had dat je je muis moest blijven bewegen

[Woudloper]

Nu ik ook maar even

Het werkt hier op mijn laptop (500 Mhz met 198 intern) ook prima....

[Pelle]

Op vrijdag 14 juni 2002 16:23 schreef Clay het volgende:
Maar het speelveld zal eerder duizend(en) bij duizend(en) pixels zijn dan 640 480, en dan heb je al een miljoen arrayposities. Het lijkt mij eigenlijk onhaalbaar om dat zo te doen.

Je moet niet voor elke pixel op gaan slaan of je er kunt lopen of niet. Het lijkt me eerder zinvol om een veld in blokken te verdelen van zeg 30 bij 30 pixels ofzo, en 1 blok stelt dan ook 1 positie voor.
De beweging van de ene naar de andere positie kan natuurlijk wel smooth, met stapjes van 1 pixel.

Dit loopt hier op mijn werk (p800 oid) prima. 40 bij 40 gaat schokken, en nog meer zorg voor zo'n "dit script trekt te veel, wil je nokken?" melding.

Ging aardig hier @ athlon1000 @ 1600x1200.

[drm]

Pelle:
Je moet niet voor elke pixel op gaan slaan of je er kunt lopen of niet. Het lijkt me eerder zinvol om een veld in blokken te verdelen van zeg 30 bij 30 pixels ofzo, en 1 blok stelt dan ook 1 positie voor.

zoals reeds gezegd is met name 'tiles'

De beweging van de ene naar de andere positie kan natuurlijk wel smooth, met stapjes van 1 pixel.

logisch. dat trekt ook lang zo veel niet.

_edit:
hier looptie wel aardig. @P3 450 (rustig maar, dit is op m'n werk )

[Bosmonster]

Op vrijdag 14 juni 2002 16:30 schreef Pelle het volgende:

[..]

Je moet niet voor elke pixel op gaan slaan of je er kunt lopen of niet.[..]

Precies.. boundaries zijn voldoende over het algemeen.

[Verwijderd]

Klootjes dus Want met een dergelijke omvang van een blok is niet echt werkbaar op grafisch gebied.

Waar ik al wel aan heb gedacht is om niet te gaan scrollen door de map, maar alleen door de objecten op die map. Dan hoeft de browser ook de achtergrond niet telkens te berekenen, welke toch een texture is.

Tevens hoef je niet echt een algehele sprite op te zetten. Je hoeft alleen de plekken te definieren welke bezet zijn. Als je deze plek controleerd en er staat wat op krijg je netjes een true terug. Als er niets op deze plek staat krijg je een undefined js error terug. Prima toch

We roepen dan een plek in de sprite aan welke niet gedefinieerd is, en ook niet allocated is in het geheugen Alleen de bezette plekken zijn allocated.

Oftewel, als ik ga testen op x:200 en y:150 -> MijnSprite[200,150] en deze is niet eens aangemaakt bij init, krijg ik een undefined terug van JS. Als ik tijdens init op deze plek een boompje heb geplaatst krijg ik een true terug.

Zo ga je dus alsnog op pixel niveau werken, en ik denk dat je zo toch nog wel performance eruit kunt halen

Of niet?

[Clay]

Anders prog je een minimale collision test in elkaar met het pixel principe. Ik wil het best wel in actie zien namelijk

Pelle

[..]

Je moet niet voor elke pixel op gaan slaan of je er kunt lopen of niet. Het lijkt me eerder zinvol om een veld in blokken te verdelen van zeg 30 bij 30 pixels ofzo, en 1 blok stelt dan ook 1 positie voor.
De beweging van de ene naar de andere positie kan natuurlijk wel smooth, met stapjes van 1 pixel.

Jah, natuurlijk, maar dat zegt ie niet het gaat over lijsten met 0en en 1en en per pixel collision, als ik het tenminste goed begrijp.

[oh,when?]

* oh,when? heeft het gevoel alsof zijn post genegeerd worden

maar goed...dan maar ff met een link strooien:

http://www-cs-students.stanford.edu/~amitp/gameprog.html#Tiles

Your map is probably going to require the most RAM. Even a relatively small map can require a suprisingly large amount of RAM. A 100x100 map requires 10,000 map cells. If each map cell is 20 bytes, that's 200K. That's not so bad, but once you move your map to 500x250 you suddenly have 125,000 map cells at 20 bytes each using up 2.5MB of RAM. And if those maps seem small to you and what you really want is something like a 1,000x1,000 map for your mega-massive C&C clone, you'll need 20MB of RAM just for the map! For that reason, you should consider making your map cell data structure as small as you possibly can, even it costs you a minor performance hit. For instance, if a particular type of data only requires 3-bits of information try to use a bitfield (or least only 1 8-bit byte or unsigned char) instead of just allocating an "int" (32-bits) to hold it. If you simply cannot make the map cells any smaller, then you're going to need to accept a smaller map size or figure out some sort of "paging" mechanism so that you don't need the whole map in memory all at once (though you might be able to rely on virtual memory if you don't mind the performance hit).

http://www.gamedev.net/reference/programming/features/arttilebase/page4.asp

[Pelle]

* Pelle denkt dat er hier wat langs elkaar heen wordt geluld

Als je het over pixel-nauwkeurige collision-detection gaat hebben, dan gaat dat vrees ik wel even wat performance kosten. Waarom zou je pixel-nauwkeurige collision detection gebruiken als je grid toch veel groter is?
Het lijkt me het handigst om 1 unit per grid-vlak toe te staan. 2 units in 1 grid-vak = collision.

[drm]

* oh,when? heeft het gevoel alsof zijn post genegeerd worden

maar goed...dan maar ff met een link strooien:

http://www-cs-students.stanford.edu/~amitp/gameprog.html#Tiles
http://www.gamedev.net/reference/programming/features/arttilebase/page4.asp

sorry oh,when?

heb niet echt de tijd op mijn werk om artikelen door te spitten... volgende week heb ik wat meer tijd, en dan zal ik eens pogen wat zooi samen te vatten.

ik kan vanavond wel ff iets fixen dat die links ook op dat gare siteje komen te staan (we moeten ze toch ergens groeperen? )

[drm]

Pelle:
Als je het over pixel-nauwkeurige collision-detection gaat hebben, dan gaat dat vrees ik wel even wat performance kosten. Waarom zou je pixel-nauwkeurige collision detection gebruiken als je grid toch veel groter is?
Het lijkt me het handigst om 1 unit per grid-vlak toe te staan. 2 units in 1 grid-vak = collision.

Units mogen colliden (iig in starcraft wel). Units mogen niet met gebouwen etc. colliden.

_edit:

then again, wat is een 'unit'

[Pelle]

Op vrijdag 14 juni 2002 16:48 schreef drm het volgende:
Units mogen colliden (iig in starcraft wel). Units mogen niet met gebouwen etc. colliden.

Grote groundunits mogen niet colliden toch? Vliegende units wel, en groundtroops ook (tenminste, meerdere units op 1 gridvlak), maar ik heb bijvoorbeeld nog nooit 2 siege-tanks over elkaar heen zien rijden.

/edit
Unit is dus een hydralisk of een siegetank of een lurker of een ghost of een battleship of een dragoon of of of of

[drm]

Pelle:
Grote groundunits mogen niet colliden toch? Vliegende units wel, en groundtroops ook (tenminste, meerdere units op 1 gridvlak),

ja da's waar...

* drm riep te snel

maar ik heb bijvoorbeeld nog nooit 2 siege-tanks over elkaar heen zien rijden.

Ik wel, maar 't was iig niet de bedoeling

_edit:
Ook wat dat betreft is dus de 2^e manier van een map definieren dus beter (zie paar posts terug van Clay)

oh,when? quote ook nog een stukje uit een van de artikelen over performance qua map

woei, dat wordt dus een hoop met bitmasks werken. lovely

[Clay]

Ik post deze toch ff, al is die vrij oud:


_{klikkerdeklik}

Ergens in december vorig jaar ben ik hier ooit aan bezig geweest. Dit is dus een soort isometrische map builder, waarbij je gebruikmakend van het menu rechts dingen in het landschap kan toevoegen, maar;

als we dit nu hetzelfde zouden doen zou dus elk stuk rots of modder anders dan de default ondergrond een aparte layer moeten zijn, en in een groot speelveld wordt dat dus een mega grote hoeveelheid layers; niet haalbaar imo.
De enige manier om het isometrisch dan toch op te bouwen is door 2 tables over elkaar heen te leggen, omdat het werkelijke (x,y) punt van een isometrische ruit precies midden in de ruit er linksboven van ligt.
Nadeel is dan alleen wel dat je vakken elkaar niet kan laten overlappen op zo'n manier dat een unit erachterlangs zou kunnen (muren, bomen), maar we zitten hoe dan ook aan bepaalde beperkingen vast
2 over elkaar liggende tables en een isometrische js stuctuur die per veld weet of je naar een ander veld kan lijkt mij goed haalbaar om te bouwen, ik wil dus voorstellen hier een kleine test voor te bouwen enige punt is dan; wat worden de dimensies voor 1 ruit?

[Verwijderd]

Kan ik ook meedoen? Kan niet zo goed programmeren (wel gewoon een beetje HTML en voor een spel GraalScript maar ik weet niet of dat ongeveer hetzelfde is, van GraalScript zeggen ze dat het op C++ lijkt) maar misschien kan ik graphix of zo maken of meehelpen met site/betatesten

[Verwijderd]

In ieder geval: W3C en Linux/Mac OS (X) compatible, dus W3C compatible lijkt me het beste

[Verwijderd]

Een heel interessant path-following scriptje:

http://www.dynamicdrive.com/dynamicindex11/pathgenerate.htm

En een note over scrollen. Waarom zou je dat niet aan de browser overlaten? Er komen hele mooie scrollbars wanneer je map niet op 1 scherm past. Dan hoef je alleen nog maar het menu op een fixed position te houden.

[oh,when?]

Op zondag 16 juni 2002 10:18 schreef daxx909 het volgende:
Een heel interessant path-following scriptje:

http://www.dynamicdrive.com/dynamicindex11/pathgenerate.htm

nou is niet zo heel erg interesant / nuttig, want dit script genereerd gewoon een array van coordinaten die de layer dan volgt. Wij hebben het over een algoritme dat van een A-punt naar B-punt moet gaan in de korts mogelijke route, het zogenaamde pathfinding. Daar zijn natuurlijk verschillende oplossingen voor, waar het A* ( A- star ) algoritme vaak word gebruikt omdat het lekker simpel en redelijk efficient is.