Director project "platform game"

[Verwijderd]

Ik ga in Director een soort van platvorm game maken waarin ik een mannetje in een soort 3D omgeving wil laten lopen (doormiddel van pijltjes toetsen), met een aanzicht van schuin boven (zie voorbeeld op afbeelding)



Nu ben ik geen Director expert maar denk ik wel dat ik een manier heb uitgedacht waarop ik het mannetje kan laten lopen zonder dat hij door muren en meubels heen kan. De vraag is alleen of dit de beste manier is om dit op te lossen.

Het werk als volgt:

Er zal een transparante psd file worden geïmporteerd die de vorm heeft van het oppervlak waar het mannetje niet mag lopen. Daaroverheen projecteer ik in diverse lagen de muren en meubels, die ik visible en niet visible maak aan de hand van de positie van zijn voeten (zodat hij niet achter een muur kan staan terwijl hij er eigenlijk voor staat) het lopen wil ik als volgt oplossen:
(ff in bescheten uitleg)

als je op links drukt en de locatie van de voeten van het mannetje -2 raken niet de transparante psd file, dan moet het mannetje 2 naar links.

Als hij wel de psd aanraakt mag hij niet naar links. Enz. enz..

Is dit de makkelijkste/beste manier om dit op te lossen of zijn er mensen die betere ideeën hebben?

[ACM]

Mocht je zelf nog verder willen zoeken, zoek dan op de termen:
collision detection

er zijn een aantal 'standaard' algoritmen voor die niet allemaal even makkelijk toe te passen zijn.
Een van de dingen waar je wellicht nog niet rekening mee gehouden hebt is dat als iemand 3 opzij gaat hij dwars door een muur heen is en alsnog de muur niet aanraakt...

[edit]
* ACM slaapt nog ofzo

[Postman]

Op zich is dit een vrij leuke oplossing. Zover ik weet gebruiken ze bij meer spellen transparante layers om te zorgen dat je niet door muren of uit levels loopt. Leuk voorbeeld is die onzichtbare muur in CS (grote open levels, worden meestal zo gemaakt dat je die muur niet tegen komt).

[stfn345]

collision detection?

Ah tis al verbeterd..

[Soultaker]

Platform, alsjeblieft.

[Verwijderd]

Op maandag 18 maart 2002 23:54 schreef Soultaker het volgende:
Platform, alsjeblieft.

Shame on me! Sorry

[Janoz]

Trouwens.. Dit noem je een 'isometric engine'. Nog een term waarmee je bergen informatie vindt

[D2k]

ik move deze naar W&G
daar zitten de director experts


P&W -> W&G
mocht je nou zeggen van " nee daaar wil ik niet naartoe" moet je me maar ff mailen dan haal ik hem wel trug

[Bosmonster]

Lastigste is nog een AI die de muren ook herkent en dan nog de snelste route naar jou vindt.. 'path finding' heet dat geloof ik.

Er zijn professionele programmeurs die daar nog moeite me hebben (kijk maar naar veel pro-games).

[Verwijderd]

Ik ga je ff een zooi keywords geven:

Je bent aan het bouwen : een isometrisch spel.
Dit spel is als het goed is tile based.
Als het idd tile based is, is het niet moeilijk om het A* pathfinding algorithme te gebruiken.

Zoek en gij zult...

[XangadiX]

...eeuwig dwalen?

[Verwijderd]

Isometric games in Director zijn Erg moeilijk om te maken. Als je het mannetje stapje voor stapje wilt laten bewegen is dat op zich wel easy te maken en ik wil je er best bij helpen met wat zooi, maar ik begon dus meteen met het lastigste, gewoon in het veld klikken a la diablo en Fallout maar dat is dus echt retelastig.

Kijk maar eens op www.geenkaas.nl dan shockwave uit het menu, dan movement02 engine aanklikken. veld van 8x8 tiles waar je op kan klikken, een tile is weg en daar loopt de speler redelijk netjes omheen als je er achter klikt maar damn dat was lastig.

Maar als je een leuk idee voor een spelletje hebt moejje maar even meelen, ik heb wel zin om weer een director projectje op te starten.

[Clay]

Collision is idd een leuke uitdaging maar ik denk wel dat je hier een lastige variant hebt (niet dat ik een expert ben ofzo )

Wat mij het handigste lijkt is om je veld gewoon isometrisch uit een grid op te bouwen (dus met grid vlakken die schuin staan) en dat elk gridvlak zijn 4 buren kent, en weet of de player daar uberhaupt heen mag lopen. Zo heb ik een keer pacman gemaakt. voordeel daarvan is dat je veld een kilometer bij een kilomter kan zijn, zonder dat dat zwaar op je performance slaat, je berekent immers altijd maximaal 4 buurvelden.

Operation 043 (zie sig) is weer heel anders. Daar heb ik een "level" file waar gewoon een lijst inzit met de maten en posities van alle blokken waar de player mee kan botsen. Bij de init van het level wordt dat in vertikale stroken van 10 of 20 pixels gehakt, en de collision hoeft dus alleen in de vertikale strook te kijken waar de player inzit. Hoe breed het level is maakt dus voor performance niet uit, hoe hoog het is wel, maar dan moet je een level wel gruwelijk hoog maken wil dat boeien. Bij liften wordt de collision in de desbetreffende stroken geupdate. Dat is trouwens ook iets waar je over na moet denken denk ik, hoe je dynamische collision gaat doen.

Ik ben nu bezig met een semi-volwaardig 2D collision systeem, dus totale collision van objecten met willekeurige veelhoeken, en dat is best kut maar wel ontzettend tof om te doen. Daarmee ben je van een collision grid af en kan je echt vette dingen gaan maken Dat point en click lopen zal dan wel een flinke dobber worden...

Dat zijn nog maar 3 vormen van collision, en zo zullen er nog veel meer zijn. Ik weet niet in hoeverre je in Director met je resources kan omgaan qua hoe zwaar het worden mag, maar het is altijd wel goed om een zo licht mogelijke variant te bedenken.

De transparante psd file klinkt goed. Da's een techniek die ik zelf alleen nooit gebruiken kan games maken roelt.

* Clay wil hier best over meedenken

[Verwijderd]

Op woensdag 20 maart 2002 09:45 schreef Clay oa het volgende:
Wat mij het handigste lijkt is om je veld gewoon isometrisch uit een grid op te bouwen (dus met grid vlakken die schuin staan) en dat elk gridvlak zijn 4 buren kent, en weet of de player daar uberhaupt heen mag lopen. Zo heb ik een keer pacman gemaakt. voordeel daarvan is dat je veld een kilometer bij een kilomter kan zijn, zonder dat dat zwaar op je performance slaat, je berekent immers altijd maximaal 4 buurvelden.

Op die fiets (aangeven of je wel of niet op die tiles mag lopen) werkt ook het zogenaamde RPGMaker, een programma om RPG's a la Final Fantasy voor de SNES etc. te maken, nouja maken... tis meer in de stijl van "Just add bitmaps!"
Bij RPGMaker 2000 (d8 ik) kon je zelfs aangeven of het poppetje en over mocht lopen, en dan van welke kant wel of niet.

[Verwijderd]

Wat ook een leuke truuk voor collision detection is is de volgende:

Je maakt een 1bit zwart wit plaatje met het gebied waarin de speler mag rondhobbelen. on exitframe check je of ie within is. Verder maak je op de vier randen een kader (ook 1 bit matte sprites), die kan best lelijk zijn, gewoon een blob oid die er overhen valt. Op het moment dat de speler uit het veld raakt check je welke van de vier blobs hij raakt en daarmee zie je precies welke kant de speler moet terugkaatsen. Zo heb ik een race spelletje gemaakt, zal die nog eens online zetten. is met 2 spelers op een keyboard te spelen

Anyhoe, ik ben wel voor een leuk projectje om iets gers in elkaar te zetten.

[Verwijderd]

kortom je wil habbo hotel namaken
heb ooit es een begin gemaakt.
ik deed dat door verschillende verdiepingen aan kleurcodes te verbinden. je krijgt dan een simpel opgezet plaatje met tiles, waarvan sommige tiles een andere kleur/hoogte hebben. Hier leg je de interface overheen zodat je tiles niet zichtbaar zijn. Dan ga je kijken wel kleur je binnenkomt door op sprite niveau te kijken.
Ik hoop zo eerst genoeg info te hebben verstrekt.
En je CD bepaal je door middel van de kleuren.
met pijltjes toetsen is dit prima te doen, met de muis iets minder.

Als ik het nog ergens kan vinden post ik het wel.

[Verwijderd]

Dat is precies wat de opdracht is voor school...
Ook Grafisch Lyceum?

[Verwijderd]

collision detection lijkt me voor mij wel erg moeilijk, zeker aangeizen ik duidelijk geen director exper ben .

Ik ben net begonnen met wat uit te proberen (heel klein beetje dan doormiddel van het nachecken op het mannetje na het verplaatsen nog intersects met de ondergrond (een transporant psd filetje)

Verder zit ik toevallig idd op het Grafisch Lyceum (Eindhoven) Maar dit was niet echt een opdracht meer een eigen idee voor een onderdeel van ons eindproject.

[Verwijderd]

hmmz.. het lijkt erop dat mijn manier niet echt functioneel is, ik heb het volgende gedaan:

code:

on keydown
  if sprite 10 intersects sprite 1 and the keyCode = 126 then
    set the locV of sprite 10 to the locV of sprite 10 -4
    set the LocH of sprite 11 to the locH of sprite 10
    set the LocV of sprite 11 to the locV of sprite 10 -18   
  else
    set the locV of sprite 10 to the locV of sprite 10 +8
    go to the frame    
  end if

en dan natuurlijk voor iedere richting..
dat gaf het volgende resultaat:
mannetje in huisje
(let niet op de layout, is enkel maar om te testen)

het mannetje blijft dus vaak vast zitten tussen muren en kan kan ook door diverse muren heen. Dat het mannetje altijd voor een muur staat klopt maar das van latere zorg

[Verwijderd]

Op donderdag 21 maart 2002 00:39 schreef tuup het volgende:
dat gaf het volgende resultaat:
mannetje in huisje
(let niet op de layout, is enkel maar om te testen)

het mannetje blijft dus vaak vast zitten tussen muren en kan kan ook door diverse muren heen. Dat het mannetje altijd voor een muur staat klopt maar das van latere zorg

Het ziet er nu ook erg vreemd uit, omdat je grid niet paralel ligt aan je 'kijkrichting'. Het grid is dus niet isometrisch en je afbeeldingen wel. Hierdoor lijkt de manier van bewegen niet te kloppen.

[Verwijderd]

Leuk begin, Alleen het is nog een beetje buggy ja, Je kan je code nog wat uitbreiden door hem per klik niet alleen over de x-as maar ook over de Y-as te laten bewegen (x=2,y=1) zodat ie mee blijft lopen. COllision detection is nog ruk, daar moet je echt een retestrak systeem voor bedenken alvorens je doorgaat. Verder kan je goed gebruik maken van de locZ om te zien welke sprite voor je player moet komen.

Hier nog een gestreamlinede code BTW:

property my

on beginSprite me
my = sprite(me.spriteNum)
end beginSprite

on keyDown
if my.intersects (1) and the keyCode = 126 then
my.locV = my.locV - 4
sprite(11).locH = my.locH
sprite(11).locV = my.locV - 18
else
my.locV = my.locV + 8
end if
end keyDown

Dit stukkie code hang je als behaviour aan je player, das handiger dan het in de frameScript te gooien, scheelt een hoop werk en maakt je code netter en beter leesbaar.

in het framescript hang je alleen dit:

on exitFrame me
go the frame
end exitFrame

Dan doet je filmpie precies hetzelfde maar het is een stuk korter en Director vind het nog fijner om mee te werken ook.

Ik snap alleen de opzet van je code niet helemaal. Sprite(10) is je player? maar wie is die sprite(11) dan? een nep-object die wat regelt voor je?

Succes in any case

[Verwijderd]

Op dinsdag 19 maart 2002 10:32 schreef Bosmonster het volgende:
Lastigste is nog een AI die de muren ook herkent en dan nog de snelste route naar jou vindt.. 'path finding' heet dat geloof ik.

Er zijn professionele programmeurs die daar nog moeite me hebben (kijk maar naar veel pro-games).

Zoals de mensen van Westwood

[Verwijderd]

Sprite 11 is het poppetje zelf, sprite 10 is een blokje aan zijn voeten, sprite 11 is dus enkel alleen maar ter "versiering"

Wat ik nu ga proberen is om zijn positie variable te maken, Dan kan ik checken of hij na het bewegen nog in het veld staat en zo ja dat hij mag verplaatsen, dan zullen er alvast een hoop bug verdwijnen..

zo en nu ga ik maar eens bedenken hoe ik die variabelen ga aansturen.

[Verwijderd]

Da kan makkelijk met 2 nieuwe properties, dus dan worden de eerste paar regels als volgt van de behaviour:

property my,myH,myV

on beginSprite me
my = sprite(me.spriteNum)
myH = my.locH
myV = my.locV
end beginsprite

Daarna kan je de myH in dezelfde behaviour altijd aanroepen en aanpassen, dus van onkeydown > myH = myH +4 of on exitframe me > my.locH = myH om het poppetje zelf goed te zetten.