Anmelden
Registrieren
Sonntag, 7. Juni 2015, 18:26
Z Levels - realistische Höhenunterschiede dem Maker beibringen
Servus!
Lang ist es her, hui ... das ändert sich in naher Zukunft hoffentlich bald
. Wie auch immer, da ich diese Anfrage bereits im englischen Forum gestellt habe, werden ich diese einfach per Copy&Paste hier einfügen. Dennoch ein kurzer deutscher Überblick, um was es überhaupt geht:
Leider haben wir, mit den Mitteln welche uns der XP liefert, keine wirklich gute Möglichkeit dem System tatsächliche Höhenunterschiede zu vermitteln. Bedeutet im Endeffekt, der Spieler und Events (NPC's z.B.) können zwar optisch von der Höhe her von einander getrennt sein allerdings fehlt die Logik dafür. Der Maker denkt in diesem Fall weitehrin, alles befindet sich auf der einen und gleichen Ebene. Kommt ziemlich schnell zum Tragen wenn es darum geht beispielsweise eine Brücke im Spiel zu haben. Es gibt zwar (teils fummelige) Möglichkeiten durch Events, Terrain Tags usw. je nachdem wo sich der Spieler befindet dem System mitzuteilen wann der Spieler nun überdie Brücke läuft und entsprechend korrekt gezeichnet wird oder eben darunter läuft und verdeckt wird. Das Problem bei der ganzen Sache ist eben nur, der Spieler. Bzw. ... es gilt nur für den Spieler. Möchte man den Spieler über die Brücke schicken und gleichzeitig NPC's darunter, mit korrekter Berücksichtigung von Collision, Passage Settings, Priorities usw. merkt man ganz schnell ... nix da, dat geht net! Die Brücker ist hierbei nur ein Beispiel, gilt eben so für Berge, Anhöhungen usw. Ich hab mir in letzter Zeit intensiv Gedanken gemacht wie es mit Hilfe eines motivierten und pfiffigen Skripters möglich wäre dem Maker Höhenunterschiede beizubringen. Das möchte ich hier nun präsentieren mit der Bitte, ob nicht jmd. bereit dazu wäre sich der Sache anzunehmen. Ich denke, das würde uns Developern ziemliche schöne Möglichkeiten für neue Gameplay Mechaniken und Konzepte in die Hände spielen. Ein genaues Fallbeispiel mit den entsprechenden Lösungen und meinen Gedanken folgt (Auszug aus dem anderen Forum):
---------------------------
Hello Folks,
Our beloved Maker (i'm talking about XP) has three Layers for building shiny Worlds, beside the Event and Fog/Panorama Layer. Though 2D, you can create the illusion that there is acutally some Height on the Map, i.e. Hills with different Levels, Mountains and so on. With the Help of the Priority and Passage Settings you create the Illusion for the Player, that he stands above or below something. But this is breaking step by step when we, the developer, think about cool Ideas like Bridges for example that our Player can cross above and below. Sure, there are Solutions for this. You can help yourself out with Events, Terrain Tags and so on. It works but itis not cool and works only for the Player. Take the Bridge Example again, where the Player and some NPC's give the Illusion they are on different Levels but in reality ... they are not. The Player wants to cross a Bridge and at the same Time a NPC wants to go under the Bridge? Nah! Create cool Dungeons and Situations like in Zelda - Link to the Past where Players and Enemies could act on different Levels in the same Situation? Nah! Just look at this Picture here i made:
Thats actually my goal i want to achieve. The Situation on this Screenshot is, with the tools we are given at the Moment, not possible! Aluxes (our Player) is on a higher level than the blue Knight next to him for instance. So, logically, they should not interact and collide with each other and the Tiles affecting them should behave (passage and priority settigns) right and be drawn properly like you see above. Like said, it is not possible in the Moment because the Maker do not know what Elevation is. So we have to teach him.
There are actually two Solutions i've came up with. Question is which one is the more smarter approach and, performance wise, the better. But, first i'll write down what is generally needed for both solutions so we have a base. Please take a look:
General
- Z Level Variable
NPC's and the Player need a Variable that tracks and saves a value. This Value would be the actual Z level. It can change when the Player and/or a NPC walk from one Z level to another visualizing by Stairs for instance. That could be triggered easy through a Event touch/Player touch Event which changes the Z level Variable for that specific Event or the Player. The most important part here is the Variable. I think some sort of a local Variable for each Event and the Player (like a local Switch) would be the best.
- Collision/Trigger Detection only on same Z Level
Because every NPC and the Player have stored a specific Z Level Value, thanks to our Z level Variables, we can now teach the System if Events and Player should collide and interact with each other or not. When it comes to collision/triggering it should be checked, if a Player/Event is on the same Z level. If yes, well... do your thing. If no, ignore that one and just move through.
Great, those are the Things we need in any Case, now we are getting to the actual Solutions i've came up with:
Solution 1 - Z Terrain Tag
So you all know Terrain Tags, they are very helpfull. For this Solution we need an equivalent system for only one purpose: tagging specific Tiles with a Z level.
I know there are Scripts out there which offer unlimited Terrain Tags instead of only 7. Thats fine but we need the possibilty to give Tiles a normal Terrain Tag and another Value (or Values) at the same Time. And here comes the Z Terrain Tag System into Action.
- Passage Detection only on same Z Level
If you have Characters on different Z Levels they should can logically walk below and above on the specific Tiles which sperates their Z Level in the same Moment and on the same Map, right? In our example above it is the upper Cliff Tile. So for our Player Aluxes this one should be considered:
For the blue Knight next to him this one here should be the logically way:
To make this possible we would need those Tiles duplicated in our Tileset, each Tiles with the specific Passage and Priority Setting. Like this:
Now, take look at this Example here:
The Tileset for this Maps would look like this (i made a screenshot with the Passage and Priority Setting):
As you can see, i marked the Tiles with different Colors. When you look at the map above again, you can count 1 and 1 together. The blue Tiles in the Tileset were used on the Positions where the blue Color on the Map is. Same Procedure for the red ones. Now, thats important, the Tiles with the purple Color are not important to Mapping at all. But it is needed because those Tiles have the other Passage and Priority Settings and serve as a "source" for the System where it gets the different Settings when the Z Level Check does not match. In pseudo Code it would look like this:
Situation:
Player/Event is moving one tile left and there is a upper Cliff Tile
Now, for instance, for our blue Knight NPC it would like this:
So, as we can see, for each Z Level we just need another duplicate of the specific Tiles, marked with a higher Z Terrain Tag.
- Drawing Tiles/Events/Player on the right Z Level
Okay, we have the Passage Detection settled but one important thing is still unclear. The Sprites have to be drawn correct and in the right Order (with considering their Priority Settings too), accordingly to their Z Levels.
This could be done with increasing/decreasing the sprite_z Value of the specific Sprites. So, how would it look like? When the Player or/and a Event change their Z level, their sprite_z Value would increase or decrease by 32, for instance, for each level of priority. Actually easy, but we need to increase the sprize_z Value for the Tiles with a Z Terrain Tag too (same Procedure). So, for instance, the upper Cliff Tile with a Z Terrain Tag of 1 has the standard sprite_z value. The Upper Cliff Tile with a Z Terrain Tag of 2 has a increased sprite_z value of 32 (like the Player or a Event would). Because of this regulation Players/Events are now drawn correctly above or below Tiles, depending on their Z Level.
Okay ... phew ... i hope that was understandable [
] . But we are not finished. That was Solution 1. We have another one.
Solution 2 - Height Maps/Pictures
I guess you all know the Pixel Movement Scripts out there. Some have a thing called collision map/picture. So as i know, you have a Picture for a specific Map on which there are colors that tell the System which Tiles or pixels are passable or not. I've taken this this approach for the Solution 2 and simply called it Height Maps/Pictures.
What is that? A Height Map/Picture is a Picture (saved in the pictures Folder) per Map which stands for one Z Level on that specific Map. Take a look at this one:
Ignore the actual Game Screenshot below. This one represents two Height Maps/Pictures we would have lying in our Pictures Folder. A Picture with only the blue color and one with only the red one. Each Color stands for one Z level.
- Passage Detection only on same Z Level
If a Map, the Player is on would have Z levels activated (could be done through a simple Switch that says yes/now), the system would check which Z Level the Player has (and the other Events of course) with the Help of the Z Level Variable and then look at the specific Z Level Picture for passage Detection. Because every Z Level Picture has a different Color and one Z Level stands for one Color (customizeable) the system knows, which Tile Passage Setting in the Tileset it should check and take into consideration. Pseudo Code would look like:
Situation:
Z Levels are present and activated on the Map and Player/Event is moving one tile left and there is a upper Cliff Tile
Actually, pretty similar to Solution 1. Difference is just, the Information which Z Level the Tiles on the Map have does not come from a Z Terrain Tag but from a Picture with it specific Color.
- Drawing Tiles/Events/Player on the right Z Level
This one is pretty similiar too. The Sprite_Z Value handling for Events and Player does not change (stays like in Solution 1). But for the Tiles, instead of drawing with a specific sprite_z value based on their Z Terrain Tag, they would be drawn based on their height map color where each color, as we know by now, stands for a specific Z Level.
Okay .. that was it. Hope i could make my point clear.
greetz
Lang ist es her, hui ... das ändert sich in naher Zukunft hoffentlich bald
. Wie auch immer, da ich diese Anfrage bereits im englischen Forum gestellt habe, werden ich diese einfach per Copy&Paste hier einfügen. Dennoch ein kurzer deutscher Überblick, um was es überhaupt geht:Leider haben wir, mit den Mitteln welche uns der XP liefert, keine wirklich gute Möglichkeit dem System tatsächliche Höhenunterschiede zu vermitteln. Bedeutet im Endeffekt, der Spieler und Events (NPC's z.B.) können zwar optisch von der Höhe her von einander getrennt sein allerdings fehlt die Logik dafür. Der Maker denkt in diesem Fall weitehrin, alles befindet sich auf der einen und gleichen Ebene. Kommt ziemlich schnell zum Tragen wenn es darum geht beispielsweise eine Brücke im Spiel zu haben. Es gibt zwar (teils fummelige) Möglichkeiten durch Events, Terrain Tags usw. je nachdem wo sich der Spieler befindet dem System mitzuteilen wann der Spieler nun überdie Brücke läuft und entsprechend korrekt gezeichnet wird oder eben darunter läuft und verdeckt wird. Das Problem bei der ganzen Sache ist eben nur, der Spieler. Bzw. ... es gilt nur für den Spieler. Möchte man den Spieler über die Brücke schicken und gleichzeitig NPC's darunter, mit korrekter Berücksichtigung von Collision, Passage Settings, Priorities usw. merkt man ganz schnell ... nix da, dat geht net! Die Brücker ist hierbei nur ein Beispiel, gilt eben so für Berge, Anhöhungen usw. Ich hab mir in letzter Zeit intensiv Gedanken gemacht wie es mit Hilfe eines motivierten und pfiffigen Skripters möglich wäre dem Maker Höhenunterschiede beizubringen. Das möchte ich hier nun präsentieren mit der Bitte, ob nicht jmd. bereit dazu wäre sich der Sache anzunehmen. Ich denke, das würde uns Developern ziemliche schöne Möglichkeiten für neue Gameplay Mechaniken und Konzepte in die Hände spielen. Ein genaues Fallbeispiel mit den entsprechenden Lösungen und meinen Gedanken folgt (Auszug aus dem anderen Forum):
---------------------------
Hello Folks,
Our beloved Maker (i'm talking about XP) has three Layers for building shiny Worlds, beside the Event and Fog/Panorama Layer. Though 2D, you can create the illusion that there is acutally some Height on the Map, i.e. Hills with different Levels, Mountains and so on. With the Help of the Priority and Passage Settings you create the Illusion for the Player, that he stands above or below something. But this is breaking step by step when we, the developer, think about cool Ideas like Bridges for example that our Player can cross above and below. Sure, there are Solutions for this. You can help yourself out with Events, Terrain Tags and so on. It works but itis not cool and works only for the Player. Take the Bridge Example again, where the Player and some NPC's give the Illusion they are on different Levels but in reality ... they are not. The Player wants to cross a Bridge and at the same Time a NPC wants to go under the Bridge? Nah! Create cool Dungeons and Situations like in Zelda - Link to the Past where Players and Enemies could act on different Levels in the same Situation? Nah! Just look at this Picture here i made:
Spoiler
zum Lesen den Text mit der Maus markieren
Thats actually my goal i want to achieve. The Situation on this Screenshot is, with the tools we are given at the Moment, not possible! Aluxes (our Player) is on a higher level than the blue Knight next to him for instance. So, logically, they should not interact and collide with each other and the Tiles affecting them should behave (passage and priority settigns) right and be drawn properly like you see above. Like said, it is not possible in the Moment because the Maker do not know what Elevation is. So we have to teach him.
There are actually two Solutions i've came up with. Question is which one is the more smarter approach and, performance wise, the better. But, first i'll write down what is generally needed for both solutions so we have a base. Please take a look:
General
- Z Level Variable
NPC's and the Player need a Variable that tracks and saves a value. This Value would be the actual Z level. It can change when the Player and/or a NPC walk from one Z level to another visualizing by Stairs for instance. That could be triggered easy through a Event touch/Player touch Event which changes the Z level Variable for that specific Event or the Player. The most important part here is the Variable. I think some sort of a local Variable for each Event and the Player (like a local Switch) would be the best.
- Collision/Trigger Detection only on same Z Level
Because every NPC and the Player have stored a specific Z Level Value, thanks to our Z level Variables, we can now teach the System if Events and Player should collide and interact with each other or not. When it comes to collision/triggering it should be checked, if a Player/Event is on the same Z level. If yes, well... do your thing. If no, ignore that one and just move through.
Great, those are the Things we need in any Case, now we are getting to the actual Solutions i've came up with:
Solution 1 - Z Terrain Tag
So you all know Terrain Tags, they are very helpfull. For this Solution we need an equivalent system for only one purpose: tagging specific Tiles with a Z level.
I know there are Scripts out there which offer unlimited Terrain Tags instead of only 7. Thats fine but we need the possibilty to give Tiles a normal Terrain Tag and another Value (or Values) at the same Time. And here comes the Z Terrain Tag System into Action.
- Passage Detection only on same Z Level
If you have Characters on different Z Levels they should can logically walk below and above on the specific Tiles which sperates their Z Level in the same Moment and on the same Map, right? In our example above it is the upper Cliff Tile. So for our Player Aluxes this one should be considered:
For the blue Knight next to him this one here should be the logically way:
To make this possible we would need those Tiles duplicated in our Tileset, each Tiles with the specific Passage and Priority Setting. Like this:
Now, take look at this Example here:
Spoiler
zum Lesen den Text mit der Maus markieren
The Tileset for this Maps would look like this (i made a screenshot with the Passage and Priority Setting):
Spoiler
zum Lesen den Text mit der Maus markieren
As you can see, i marked the Tiles with different Colors. When you look at the map above again, you can count 1 and 1 together. The blue Tiles in the Tileset were used on the Positions where the blue Color on the Map is. Same Procedure for the red ones. Now, thats important, the Tiles with the purple Color are not important to Mapping at all. But it is needed because those Tiles have the other Passage and Priority Settings and serve as a "source" for the System where it gets the different Settings when the Z Level Check does not match. In pseudo Code it would look like this:
Situation:
Player/Event is moving one tile left and there is a upper Cliff Tile
|
Quellcode |
1 2 3 4 5 6 7 8 9 |
- Check if Tile has a Z Terrain Tag
- Yes
- Check if Player/Event Z Level is <= as the Tile Z Terrain Tag
- Yes
take Passage Setting from the Tile id xx in consideration
- No
take Passage Setting from the Tile id yy in consideration
- No
Do nothing |
Now, for instance, for our blue Knight NPC it would like this:
|
|
Quellcode |
1 2 3 4 5 6 7 8 9 |
- Check if Tile has a Z Terrain Tag
- Yes <- it applies
- Check if Event Z Level is <= as the Tile Z Terrain Tag <- NPC has Z level 1 and Z Terrain Tag of Tiles used with blue Color is 1 too
- Yes <- it applies
take Passage Setting from the Tile id xx in consideration <- Tile ID of the Tile with blue Color with Z Terrain Tag 1
- No
take Passage Setting from the Tile id yy in consideration <- it that would applie, the System would take the Tile ID of the Tile with the purple Color, because NPC would have a higher Z Level than one (in this case 2 or higher) and should walk on those Tiles.
- No
Do nothing |
So, as we can see, for each Z Level we just need another duplicate of the specific Tiles, marked with a higher Z Terrain Tag.
- Drawing Tiles/Events/Player on the right Z Level
Okay, we have the Passage Detection settled but one important thing is still unclear. The Sprites have to be drawn correct and in the right Order (with considering their Priority Settings too), accordingly to their Z Levels.
This could be done with increasing/decreasing the sprite_z Value of the specific Sprites. So, how would it look like? When the Player or/and a Event change their Z level, their sprite_z Value would increase or decrease by 32, for instance, for each level of priority. Actually easy, but we need to increase the sprize_z Value for the Tiles with a Z Terrain Tag too (same Procedure). So, for instance, the upper Cliff Tile with a Z Terrain Tag of 1 has the standard sprite_z value. The Upper Cliff Tile with a Z Terrain Tag of 2 has a increased sprite_z value of 32 (like the Player or a Event would). Because of this regulation Players/Events are now drawn correctly above or below Tiles, depending on their Z Level.
Okay ... phew ... i hope that was understandable [
] . But we are not finished. That was Solution 1. We have another one.Solution 2 - Height Maps/Pictures
I guess you all know the Pixel Movement Scripts out there. Some have a thing called collision map/picture. So as i know, you have a Picture for a specific Map on which there are colors that tell the System which Tiles or pixels are passable or not. I've taken this this approach for the Solution 2 and simply called it Height Maps/Pictures.
What is that? A Height Map/Picture is a Picture (saved in the pictures Folder) per Map which stands for one Z Level on that specific Map. Take a look at this one:
Spoiler
zum Lesen den Text mit der Maus markieren
Ignore the actual Game Screenshot below. This one represents two Height Maps/Pictures we would have lying in our Pictures Folder. A Picture with only the blue color and one with only the red one. Each Color stands for one Z level.
- Passage Detection only on same Z Level
If a Map, the Player is on would have Z levels activated (could be done through a simple Switch that says yes/now), the system would check which Z Level the Player has (and the other Events of course) with the Help of the Z Level Variable and then look at the specific Z Level Picture for passage Detection. Because every Z Level Picture has a different Color and one Z Level stands for one Color (customizeable) the system knows, which Tile Passage Setting in the Tileset it should check and take into consideration. Pseudo Code would look like:
Situation:
Z Levels are present and activated on the Map and Player/Event is moving one tile left and there is a upper Cliff Tile
|
|
Quellcode |
1 2 3 4 5 6 7 |
- Check which Color the Tile Position the Player/Event is moving to has on the Height Map
- Blue
take Passage Setting from the Tile id xx in consideration
- Red
take Passage Setting from the Tile id yy in consideration
- No Color
Do nothing |
Actually, pretty similar to Solution 1. Difference is just, the Information which Z Level the Tiles on the Map have does not come from a Z Terrain Tag but from a Picture with it specific Color.
- Drawing Tiles/Events/Player on the right Z Level
This one is pretty similiar too. The Sprite_Z Value handling for Events and Player does not change (stays like in Solution 1). But for the Tiles, instead of drawing with a specific sprite_z value based on their Z Terrain Tag, they would be drawn based on their height map color where each color, as we know by now, stands for a specific Z Level.
Okay .. that was it. Hope i could make my point clear.
greetz
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »schM0ggi« (8. Juni 2015, 11:06)
Sonntag, 7. Juni 2015, 23:59
Das große Scientia Wiki zur Spielentwicklung 
Was ist das RGSS ? RGSS-Dokumentation auf Sc
Kyoshiros Makerkurs
Musik von Shabraxxx für euch
Guide zu den Audioformaten
Skripte von mir (Auswahl):
Atmungssystem
| Streichholzsystem | Animiert durch Bücher blättern
Random : Marktsystem für Kardor | Staterelated Battlergraphic | Hinweis auf mögliche Aktionen
SelfSwitchExpirationtimer Skript - Gameplayerweiterung für Pilzesammler und Farmspiele
Meine Skripte werden gerade hier gesammelt.
Was ist das RGSS ? RGSS-Dokumentation auf Sc
Kyoshiros Makerkurs
Musik von Shabraxxx für euch
Guide zu den Audioformaten
Skripte von mir (Auswahl):
Atmungssystem
| Streichholzsystem | Animiert durch Bücher blättern Random : Marktsystem für Kardor
| Staterelated Battlergraphic | Hinweis auf mögliche Aktionen SelfSwitchExpirationtimer Skript - Gameplayerweiterung für Pilzesammler und Farmspiele Meine Skripte werden gerade hier gesammelt.
Montag, 8. Juni 2015, 01:24
Hey Playm,
ui ui ... da is mir beim vielen schreiben und überarbeiten des Beitrags wohl was durch die Lappen gegangen und ich hab mich wirklich falsch ausgedrückt was Variante 1 betrifft. Sorry dafür!
Das Mapping ist von dem System nicht in unangenehmerweise betroffen. Der einzig wichtige Punkt ist der, dass man nur in seinem Tileset je höheren Z level die entsprechenden Tiles duplizieren und diesen den höheren Z Terrain Tag zuweisen muss. Natürlich muss man beim Mappen die Höhenunterschiede im Hinterkopf haben und die richtigen Tiles, je nach Z Level, auswählen. Aber das sollte ja kein Problem sein. Hier noch mal die korrekte Erklärung:
Ich nehme dieses Beispiel hier mit den Farben, da es sich sehr gut eignet.
Das Tileset würde für unsere Beispielmap folgendermaßen aussehen (einmal mit Priority und einmal mit Passage Settings):
Jetzt kannst du im Grunde 1 und 1 zusammenzählen. Die blau markieren Tiles im Tileset sind die blauen auf der Beispielmap. Bei den roten das gleiche in rot. Jetzt, ganz wichtig, die lila markierten Tiles im Tileset sind fürs Mapping uninteressant und dienen lediglich als "Quelle" fürs System wo er die anderen Passage und Priority Werte her bekommt wenn ein Z Level Unterschied bei der Abfrage erkannt wird (sprich, wenn er beim verschachtelten "no" landet). Hier noch mal die korrigierte Pseudo Code Abfrage:
Jetzt noch mal die Abfrage bezogen auf den blauen NPC. Dieser ist auf der Beispielmap auf Z Level 1 (Ground) und bewegt bzw. hat sich von oben nach unten auf eines der blauen Cliff Tiles bewegt:
Soweit verstanden?
ps.
Dei Vorschlag bzgl. zwei Maps und verschmelzen war mir in der Anfangsphase auch im Kopf. Ich meine sogar es gibt Skripts, die sowas in der Richtung bereits machen können aber ehrlich gesagt, das wäre sehr umständlich. Und wie du bereits sagtest, müsste man noch Aufwand in Richtung "wie lassen wir Events usw. von beiden Maps gleichzeitig anzeigen und interaktiv sein etc." betreiben. Wäre mMn eine ungünstige Variante.
greetz
ui ui ... da is mir beim vielen schreiben und überarbeiten des Beitrags wohl was durch die Lappen gegangen und ich hab mich wirklich falsch ausgedrückt was Variante 1 betrifft. Sorry dafür!
Das Mapping ist von dem System nicht in unangenehmerweise betroffen. Der einzig wichtige Punkt ist der, dass man nur in seinem Tileset je höheren Z level die entsprechenden Tiles duplizieren und diesen den höheren Z Terrain Tag zuweisen muss. Natürlich muss man beim Mappen die Höhenunterschiede im Hinterkopf haben und die richtigen Tiles, je nach Z Level, auswählen. Aber das sollte ja kein Problem sein. Hier noch mal die korrekte Erklärung:
Ich nehme dieses Beispiel hier mit den Farben, da es sich sehr gut eignet.
Spoiler
zum Lesen den Text mit der Maus markieren
Das Tileset würde für unsere Beispielmap folgendermaßen aussehen (einmal mit Priority und einmal mit Passage Settings):
Spoiler
zum Lesen den Text mit der Maus markieren
Jetzt kannst du im Grunde 1 und 1 zusammenzählen. Die blau markieren Tiles im Tileset sind die blauen auf der Beispielmap. Bei den roten das gleiche in rot. Jetzt, ganz wichtig, die lila markierten Tiles im Tileset sind fürs Mapping uninteressant und dienen lediglich als "Quelle" fürs System wo er die anderen Passage und Priority Werte her bekommt wenn ein Z Level Unterschied bei der Abfrage erkannt wird (sprich, wenn er beim verschachtelten "no" landet). Hier noch mal die korrigierte Pseudo Code Abfrage:
|
|
Quellcode |
1 2 3 4 5 6 7 8 9 |
- Check if Tile has a Z Terrain Tag
- Yes
- Check if Player/Event Z Level is <= as the Tile Z Terrain Tag
- Yes
take Passage Setting from the Tile id xx in consideration
- No
take Passage Setting from the Tile id yy in consideration
- No
Do nothing |
Jetzt noch mal die Abfrage bezogen auf den blauen NPC. Dieser ist auf der Beispielmap auf Z Level 1 (Ground) und bewegt bzw. hat sich von oben nach unten auf eines der blauen Cliff Tiles bewegt:
|
|
Quellcode |
1 2 3 4 5 6 7 8 9 |
- Check if Tile has a Z Terrain Tag
- Yes <- trifft ja in diesem Fall zu
- Check if Event Z Level is <= as the Tile Z Terrain Tag <- NPC hat Z level 1 und Z Terrain Tag von blauen Tile ist auch 1
- Yes <- trifft zu
take Passage Setting from the Tile id xx in consideration <- Tile ID von blauem Tile mit Z Terrain Tag 1
- No
take Passage Setting from the Tile id yy in consideration <- hier würde er die Tile ID vom lila Tile nehmen, da er höher als Z Level 1 wäre, in diesem Fall 2, und somit auf diesen Tiles laufen könnte
- No
Do nothing |
Soweit verstanden?
ps.
Dei Vorschlag bzgl. zwei Maps und verschmelzen war mir in der Anfangsphase auch im Kopf. Ich meine sogar es gibt Skripts, die sowas in der Richtung bereits machen können aber ehrlich gesagt, das wäre sehr umständlich. Und wie du bereits sagtest, müsste man noch Aufwand in Richtung "wie lassen wir Events usw. von beiden Maps gleichzeitig anzeigen und interaktiv sein etc." betreiben. Wäre mMn eine ungünstige Variante.
greetz
Montag, 8. Juni 2015, 20:09
Ah, ich verstehe. Das könnte klappen, aber nochmal zu dem Zeichnen der Tiles.
Wenn der Player Höhenstufe "2" erreicht, erhöht sich also sein normaler Z-Wert um einen fixen Wert - ok, das ist machbar indem man Game_Character#screen_z überschreibt. Aber wie machst Du das bei Tiles aus dem Tileset? Diese haben keinen Z-Wert. Sie haben eine Priorität zwischen 0 und 5, worraus die Tilemap Klasse ihre Z-Koordinate berechnet:
Aus Interesse habe ich mal nachgesehen, was passiert wenn man statt Priorität 5 einem Tile eine Priorität von 6 oder höher gibt: Das Tile wird nichtmehr angezeigt auf der Map. Die Tilemapklasse berücksichtigt diese Tiles beim zeichnen des Bildschirms nichtmehr, so wie es aussieht.
Ich habe ein Event diesen Code ausführen lassen:
Sollange ich da keinen Fehler gemacht habe, bedeutet das eine Schwierigkeit für dein Projekt.
Da die Tilemapklasse uns keinen Zugang zu den einzelnen Sprites bietet, müsste also ein Rewrite der Tilemapklasse verwendet werden. Diesen Umstand solltest Du bei deiner Planung bedenken.
Zitat
- Drawing Tiles/Events/Player on the right Z Level
[...] The Sprites have to be drawn correct and in the right Order (with considering their Priority Settings too), accordingly to their Z Levels.
This could be done with increasing/decreasing the sprite_z Value of the specific Sprites. So, how would it look like? When the Player or/and a Event change their Z level, their sprite_z Value would increase or decrease by 32, for instance, for each level of priority. Actually easy, but we need to increase the sprize_z Value for the Tiles with a Z Terrain Tag too (same Procedure). [...]
Wenn der Player Höhenstufe "2" erreicht, erhöht sich also sein normaler Z-Wert um einen fixen Wert - ok, das ist machbar indem man Game_Character#screen_z überschreibt. Aber wie machst Du das bei Tiles aus dem Tileset? Diese haben keinen Z-Wert. Sie haben eine Priorität zwischen 0 und 5, worraus die Tilemap Klasse ihre Z-Koordinate berechnet:
The Z-coordinate of each sprite used to create a tilemap is fixed at a specific value.
- Tiles with a priority of 0 always have a Z-coordinate of 0.
- Priority 1 tiles placed at the top edge of the screen have a Z-coordinate of 64.
- Every time the priority increases by 1 or the next tile down is selected, the Z-coordinate increases by 32.
- The Z-coordinate changes accordingly as the tilemap scrolls vertically.
Aus Interesse habe ich mal nachgesehen, was passiert wenn man statt Priorität 5 einem Tile eine Priorität von 6 oder höher gibt: Das Tile wird nichtmehr angezeigt auf der Map. Die Tilemapklasse berücksichtigt diese Tiles beim zeichnen des Bildschirms nichtmehr, so wie es aussieht.
Ich habe ein Event diesen Code ausführen lassen:
|
|
Ruby Quellcode |
1 2 3 4 5 6 |
# The first Tile in the third row tile_id = 384 + 16 # Get priority table table = $game_map.priorities # Set the Priority of this tile to 6 table[tile_id] = 6 |
Sollange ich da keinen Fehler gemacht habe, bedeutet das eine Schwierigkeit für dein Projekt.
Da die Tilemapklasse uns keinen Zugang zu den einzelnen Sprites bietet, müsste also ein Rewrite der Tilemapklasse verwendet werden. Diesen Umstand solltest Du bei deiner Planung bedenken.
Das große Scientia Wiki zur Spielentwicklung
Was ist das RGSS ? RGSS-Dokumentation auf Sc
Kyoshiros Makerkurs
Musik von Shabraxxx für euch
Guide zu den Audioformaten
Skripte von mir (Auswahl):
Atmungssystem | Streichholzsystem | Animiert durch Bücher blättern
Random : Marktsystem für Kardor | Staterelated Battlergraphic | Hinweis auf mögliche Aktionen
SelfSwitchExpirationtimer Skript - Gameplayerweiterung für Pilzesammler und Farmspiele
Meine Skripte werden gerade hier gesammelt.
Was ist das RGSS ? RGSS-Dokumentation auf Sc
Kyoshiros Makerkurs
Musik von Shabraxxx für euch
Guide zu den Audioformaten
Skripte von mir (Auswahl):
Atmungssystem
| Streichholzsystem | Animiert durch Bücher blättern Random : Marktsystem für Kardor
| Staterelated Battlergraphic | Hinweis auf mögliche Aktionen SelfSwitchExpirationtimer Skript - Gameplayerweiterung für Pilzesammler und Farmspiele Meine Skripte werden gerade hier gesammelt.
Montag, 8. Juni 2015, 21:00
Wenn der Player Höhenstufe "2" erreicht, erhöht sich also sein normaler Z-Wert um einen fixen Wert - ok, das ist machbar indem man Game_Character#screen_z überschreibt. Aber wie machst Du das bei Tiles aus dem Tileset? Diese haben keinen Z-Wert. Sie haben eine Priorität zwischen 0 und 5, worraus die Tilemap Klasse ihre Z-Koordinate berechnet:
The Z-coordinate of each sprite used to create a tilemap is fixed at a specific value.
- Tiles with a priority of 0 always have a Z-coordinate of 0.
- Priority 1 tiles placed at the top edge of the screen have a Z-coordinate of 64.
- Every time the priority increases by 1 or the next tile down is selected, the Z-coordinate increases by 32.
- The Z-coordinate changes accordingly as the tilemap scrolls vertically.
Mmhh... damn it! Ich hatte jetzt im Kopf bzw. die Hoffnung, dass Tiles ähnlich wie Characters einen z_value besitzen. Muss jetzt ehrlich gesagt sagen, den Auszug aus der Help File kann ich nicht ganz nachvollziehen, zumindest die Passage mit der Z-coordinate und dem "next tile down". Was genau ist damit gemeint? Mit Coordinate bringe ich X/Y in Verbindung. Kannst du das bitte erläutern?
Zu meiner grundsätzlichen Vorstellung:
Du erwähnst gegen Ende die Priorites bzw. hast einen Test mit einer sechsten Stufen gemacht. Die Priorities wollte ich eigentlich unangetastet lassen, zumindest von der Anzahl (0 - 5).
Ich hatte mir gedacht, dass zu Anfang des zeichnens der Map auf dem Bildschirm die Tiles, welche einen Z Terrain Tag höher 1 besitzen, auch entsprechend "höher" gezeichnet werden. Sprich, ein Cliff Tile mit einem Z Terrain Tag von 2 würde mit einer Priority von 1 nicht mit der z-coordinate 64 sondern 96 gezeichnet werden, bei Z Terrain Tag 3 mit 128 usw. (wäre das denn ohne rewrite machbar?) Es sei denn ich verstehe jetzt den Begriff z-coordinate völligst falsch!?
Ansonsten .. wenn alle strikke reißen. KK20 hat einen sehr guten Tilemap rewrite geschrieben, welches auch für den rmxpace zum Einsatz kommt. Wenn die standard Tilemap eine Sackgasse ist, müsste man sich das Teil näher anschauen oder, im schlimmsten Notfall, die eigentlichen Sprites per Event anzeigen lassen (da könnte man ja mit dem sprite_z value arbeiten) und für die Passage Abfrage eben "leere" bzw. unsichtbare Tiles verwenden. Wobei mir gerade hierzu einfällt, es gibt doch dieses "Unlimited Graphics Layer" Script von PK8 zu welchem auch shabraxx hier ein Tutorial gepostet hat. Soweit ich das gesehen habe, kann man dort doch auch kunter bunt Sprites aus dem Tileset zeichnen lassen, überlappen, verdeckt und was man eben möchte. Die Passage Geschichte und so ist da eben nicht mit drin, das weiß ich auf jeden fall. Das wäre dann im Notfall sogar eine bessere Alternative als die Sprites über Events zeichnen lassen da performance schonender.
greetz
Montag, 8. Juni 2015, 22:15
Naja, wenn das hier dein Bildschirm ist, der hier jetzt 8x4 Tiles anzeigt
dann ist das grüne Tile an der top edge des Bildschrims und das blaue Tile in der nächsten Zeile darunter (next tile down) [next tile down setzt sich über alle Zeilen fort]. Wenn der Held nun sich eins runter bewegt scrollt die Map mit und das blaue Tile ist nun an der top edge. Weißt Du denn grundsätzlich, wie sich die Z-Koordinate eines Events berechnet und warum sie so berechnet wird?
Die Tilemapklasse kann nur im ganzen angesteuert werden, um eine Map mit einem Tileset wie der RPG Maker beides definiert anzuzeigen. An die einzelnen Sprites kommt man nicht dran, auch deren Z-Koordinate kann man nicht anpassen. Man kann lediglich im Tileset Prioritäten für Tiles vergeben, die die Tilemap intern dann berücksichtigt.
Eine Z-Koordinate bestimmt bei einem Sprite ganz allgemein, wann er bei Graphics.update() gezeichnet wird. Hat Sprite_A eine Z-Koordinate von 4 und Sprite_B eine Z-Koordinate von 3, so wird zuerst Sprite_B gezeichnet und dann Sprite A. Dadurch kann Sprite_A, Sprite_B überdecken, es wirkt also so, als wäre Sprite_A mit z=4 näher am Betrachter.
Soviel dazu, ich hoffe das hilft dir schon weiter. Sonst stell sehr gerne weitere Fragen.
| ■ ■ ■ ■ ■ ■ ■ ■ |
| ■ ■ ■ ■ ■ ■ ■ ■ |
| ■ ■ ■ ■ ■ ■ ■ ■ |
| ■ ■ ■ ■ ■ ■ ■ ■ |
| ■ ■ ■ ■ ■ ■ ■ ■ |
| ■ ■ ■ ■ ■ ■ ■ ■ |
| ■ ■ ■ ■ ■ ■ ■ ■ |
dann ist das grüne Tile an der top edge des Bildschrims und das blaue Tile in der nächsten Zeile darunter (next tile down) [next tile down setzt sich über alle Zeilen fort]. Wenn der Held nun sich eins runter bewegt scrollt die Map mit und das blaue Tile ist nun an der top edge. Weißt Du denn grundsätzlich, wie sich die Z-Koordinate eines Events berechnet und warum sie so berechnet wird?
Die Tilemapklasse kann nur im ganzen angesteuert werden, um eine Map mit einem Tileset wie der RPG Maker beides definiert anzuzeigen. An die einzelnen Sprites kommt man nicht dran, auch deren Z-Koordinate kann man nicht anpassen. Man kann lediglich im Tileset Prioritäten für Tiles vergeben, die die Tilemap intern dann berücksichtigt.
Eine Z-Koordinate bestimmt bei einem Sprite ganz allgemein, wann er bei Graphics.update() gezeichnet wird. Hat Sprite_A eine Z-Koordinate von 4 und Sprite_B eine Z-Koordinate von 3, so wird zuerst Sprite_B gezeichnet und dann Sprite A. Dadurch kann Sprite_A, Sprite_B überdecken, es wirkt also so, als wäre Sprite_A mit z=4 näher am Betrachter.
Soviel dazu, ich hoffe das hilft dir schon weiter. Sonst stell sehr gerne weitere Fragen.
Hast Du einen Link zu dem Tilemap rewrite? (Vornämlich ohne die Bedingung sich vorher einzuloggen/zu registrieren). Ich denke die Standardtilemap wird dir am Ende nicht weiterhelfen können bei dem was Du vorhast.
KK20 hat einen sehr guten Tilemap rewrite geschrieben, welches auch für den rmxpace zum Einsatz kommt. Wenn die standard Tilemap eine Sackgasse ist, müsste man sich das Teil näher anschauen oder, im schlimmsten Notfall, die eigentlichen Sprites per Event anzeigen lassen (da könnte man ja mit dem sprite_z value arbeiten) und für die Passage Abfrage eben "leere" bzw. unsichtbare Tiles verwenden.
Vermutlich ja, wobei man sich überlegen könnte etwas handgemachtes zu schreiben. Das Unlimited Graphics Layer Skript könnte zu allgemein für diese Lösung sein, bzw. dadurch die Lösung komplexer gestallten als es nötig ist. Wir können uns das Skript aber auch nochmal angucken. Vielleicht auch hierzu ein Link? :3
Wobei mir gerade hierzu einfällt, es gibt doch dieses "Unlimited Graphics Layer" Script von PK8 zu welchem auch shabraxx hier ein Tutorial gepostet hat. Soweit ich das gesehen habe, kann man dort doch auch kunter bunt Sprites aus dem Tileset zeichnen lassen, überlappen, verdeckt und was man eben möchte. Die Passage Geschichte und so ist da eben nicht mit drin, das weiß ich auf jeden fall. Das wäre dann im Notfall sogar eine bessere Alternative als die Sprites über Events zeichnen lassen da performance schonender.
Das große Scientia Wiki zur Spielentwicklung
Was ist das RGSS ? RGSS-Dokumentation auf Sc
Kyoshiros Makerkurs
Musik von Shabraxxx für euch
Guide zu den Audioformaten
Skripte von mir (Auswahl):
Atmungssystem | Streichholzsystem | Animiert durch Bücher blättern
Random : Marktsystem für Kardor | Staterelated Battlergraphic | Hinweis auf mögliche Aktionen
SelfSwitchExpirationtimer Skript - Gameplayerweiterung für Pilzesammler und Farmspiele
Meine Skripte werden gerade hier gesammelt.
Was ist das RGSS ? RGSS-Dokumentation auf Sc
Kyoshiros Makerkurs
Musik von Shabraxxx für euch
Guide zu den Audioformaten
Skripte von mir (Auswahl):
Atmungssystem
| Streichholzsystem | Animiert durch Bücher blättern Random : Marktsystem für Kardor
| Staterelated Battlergraphic | Hinweis auf mögliche Aktionen SelfSwitchExpirationtimer Skript - Gameplayerweiterung für Pilzesammler und Farmspiele Meine Skripte werden gerade hier gesammelt.
Montag, 8. Juni 2015, 22:51
Okay, jetzt habe ich es dank deines verständlichen Beispiels verstanden, danke dafür! Und .. mist . Das geht dann in der Tat nicht, so wie ich mir das vorgestellt habe.
Kannst du gerne erläutern, ich hab nichts dagegen den Maker mehr zu verstehen.
Na klar, bitte [XP] XP Ace Tilemap
Der Rewrite ist, soweit ich weiß noch nicht "final", aber ein funktionierendes Spiel auf Niveau der standard Tilemap (was Features betrifft) sollte gehen. Ansonsten gibt es noch andere gute Rewrites, die meines Wissens final sind. Siehe dazu folgenden Thread:
[XP] XP Ace Tilemap
Zu erwähnen wären da die Rewrites von Terv und The King, whitflute bin ich nicht sicher was Kompatibilität mit anderen Scripts angeht.
Etwas Handgemachts, auf dieses Vorhaben hier angepasst, wäre natürlich letztendlich das sinnvollse, da stimme ich dir zu. Link zum originalen Thread :
Unlimited Graphically Layered Maps - RGSS Scripts (RMXP) - RPG Maker Forums
Link zum Tutorial von Shabraxxx inklusive Link zum Script und Download einer Demo:
Unlimited Graphically Layered Maps - RGSS Scripts (RMXP) - RPG Maker Forums
greetz
. Das geht dann in der Tat nicht, so wie ich mir das vorgestellt habe.Weißt Du denn grundsätzlich, wie sich die Z-Koordinate eines Events berechnet und warum sie so berechnet wird?
Kannst du gerne erläutern, ich hab nichts dagegen den Maker mehr zu verstehen
.Hast Du einen Link zu dem Tilemap rewrite? (Vornämlich ohne die Bedingung sich vorher einzuloggen/zu registrieren). Ich denke die Standardtilemap wird dir am Ende nicht weiterhelfen können bei dem was Du vorhast.
Na klar, bitte [XP] XP Ace Tilemap
Der Rewrite ist, soweit ich weiß noch nicht "final", aber ein funktionierendes Spiel auf Niveau der standard Tilemap (was Features betrifft) sollte gehen. Ansonsten gibt es noch andere gute Rewrites, die meines Wissens final sind. Siehe dazu folgenden Thread:
[XP] XP Ace Tilemap
Zu erwähnen wären da die Rewrites von Terv und The King, whitflute bin ich nicht sicher was Kompatibilität mit anderen Scripts angeht.
Vermutlich ja, wobei man sich überlegen könnte etwas handgemachtes zu schreiben. Das Unlimited Graphics Layer Skript könnte zu allgemein für diese Lösung sein, bzw. dadurch die Lösung komplexer gestallten als es nötig ist. Wir können uns das Skript aber auch nochmal angucken. Vielleicht auch hierzu ein Link? :3
Etwas Handgemachts, auf dieses Vorhaben hier angepasst, wäre natürlich letztendlich das sinnvollse, da stimme ich dir zu. Link zum originalen Thread :
Unlimited Graphically Layered Maps - RGSS Scripts (RMXP) - RPG Maker Forums
Link zum Tutorial von Shabraxxx inklusive Link zum Script und Download einer Demo:
Unlimited Graphically Layered Maps - RGSS Scripts (RMXP) - RPG Maker Forums
greetz
Donnerstag, 18. Juni 2015, 23:36
Eine Erkenntnis: Das realisieren von Höhenleveln ist nicht trivial.
Nehmen wir wieder dein Beispielscreen:
Wenn wir nun einen Baum auf den Hügel stellen, der über die Nord-Kante herüberragt - wie berechnen sich für die Tiles die den Baum bilden dann die Z-Koordinaten, das er korrekt angezeigt wird?
Ich bin nochmal auf die Idee zurückgekommen, die verschiedenen Höhenlevel über verschiedene Maps zu realisieren, aber kam zeitlich zuletzt nichtmehr dazu noch daran zu arbeiten. Hast Du noch Input bekommen, oder Hinweise was zu beachten ist? Ich komme gerade immer nur am Rande dazu, ein bisschen zu skripten, aber ich beschäftige mich noch damit, sollange auch andere noch Interesse an dem Problem haben.
tl;dr: Nichts ist auswegslos. Es dauert noch.
Nehmen wir wieder dein Beispielscreen:
Spoiler
zum Lesen den Text mit der Maus markieren
Wenn wir nun einen Baum auf den Hügel stellen, der über die Nord-Kante herüberragt - wie berechnen sich für die Tiles die den Baum bilden dann die Z-Koordinaten, das er korrekt angezeigt wird?
Ich bin nochmal auf die Idee zurückgekommen, die verschiedenen Höhenlevel über verschiedene Maps zu realisieren, aber kam zeitlich zuletzt nichtmehr dazu noch daran zu arbeiten. Hast Du noch Input bekommen, oder Hinweise was zu beachten ist? Ich komme gerade immer nur am Rande dazu, ein bisschen zu skripten, aber ich beschäftige mich noch damit, sollange auch andere noch Interesse an dem Problem haben.
tl;dr: Nichts ist auswegslos. Es dauert noch.
Das große Scientia Wiki zur Spielentwicklung
Was ist das RGSS ? RGSS-Dokumentation auf Sc
Kyoshiros Makerkurs
Musik von Shabraxxx für euch
Guide zu den Audioformaten
Skripte von mir (Auswahl):
Atmungssystem | Streichholzsystem | Animiert durch Bücher blättern
Random : Marktsystem für Kardor | Staterelated Battlergraphic | Hinweis auf mögliche Aktionen
SelfSwitchExpirationtimer Skript - Gameplayerweiterung für Pilzesammler und Farmspiele
Meine Skripte werden gerade hier gesammelt.
Was ist das RGSS ? RGSS-Dokumentation auf Sc
Kyoshiros Makerkurs
Musik von Shabraxxx für euch
Guide zu den Audioformaten
Skripte von mir (Auswahl):
Atmungssystem
| Streichholzsystem | Animiert durch Bücher blättern Random : Marktsystem für Kardor
| Staterelated Battlergraphic | Hinweis auf mögliche Aktionen SelfSwitchExpirationtimer Skript - Gameplayerweiterung für Pilzesammler und Farmspiele Meine Skripte werden gerade hier gesammelt.
Freitag, 19. Juni 2015, 00:01
Hallo Playm,
nun, um ehrlich zu sein, so weit habe ich (noch) nicht gedacht da die Grundlage erstmal Priorität hatte. Wo du es jedoch ansprichst, ich würde solche Fälle einfach mit Hilfe der "Z Terrain Tags" lösen. Das ist ja (theoretisch) das schöne an dieser Idee. Das bedeutet, man müsste in seinen Tilesets Sprites welche da überragen (was wohl bei den Meisten nur die Bäume betrifft) je Z Level besitzen. Sprich, plant man 3 Z Levels sollte man die Bäume drei mal im Tileset besitzen, welche eben je Z Level verschiedene Tags erhalten. Hängt im Endeffekt dann vom Developer ab, was für Maps mit vielen Z Levels usw. er plant.
Diese Idee setzt natürlich auf die Grundlage, dass Sprites welche "Z Terrain Tags" besitzen mit Hilfe von einer eigenen dafür entwickelten Lösung gezeichnet werden. Also so etwas wie das Graphics Layer Script z.B. oder im schlimmsten Fall ein Tilemap Rewrite. Hier wäre es natürlich auch am schönsten, wenn diese gezeichneten Sprites Informationen wie Priority, Bush Flags usw. aus dem Tileset besitzen, was ja beim Graphics Layer Script nicht vorhanden ist, oder man diese im Script selber setzen muss. Eins von beiden sollte zumindest vorhanden sein damit es funktioniert.
Ansonsten:
Leider gibt es niemand anderen, der Interesse hat sich einer Lösung anzunehmen :/. Entweder keine Zeit (was verständlich ist) oder keine Antworen.
greetz
nun, um ehrlich zu sein, so weit habe ich (noch) nicht gedacht da die Grundlage erstmal Priorität hatte
. Wo du es jedoch ansprichst, ich würde solche Fälle einfach mit Hilfe der "Z Terrain Tags" lösen. Das ist ja (theoretisch) das schöne an dieser Idee. Das bedeutet, man müsste in seinen Tilesets Sprites welche da überragen (was wohl bei den Meisten nur die Bäume betrifft) je Z Level besitzen. Sprich, plant man 3 Z Levels sollte man die Bäume drei mal im Tileset besitzen, welche eben je Z Level verschiedene Tags erhalten. Hängt im Endeffekt dann vom Developer ab, was für Maps mit vielen Z Levels usw. er plant.Diese Idee setzt natürlich auf die Grundlage, dass Sprites welche "Z Terrain Tags" besitzen mit Hilfe von einer eigenen dafür entwickelten Lösung gezeichnet werden. Also so etwas wie das Graphics Layer Script z.B. oder im schlimmsten Fall ein Tilemap Rewrite. Hier wäre es natürlich auch am schönsten, wenn diese gezeichneten Sprites Informationen wie Priority, Bush Flags usw. aus dem Tileset besitzen, was ja beim Graphics Layer Script nicht vorhanden ist, oder man diese im Script selber setzen muss. Eins von beiden sollte zumindest vorhanden sein damit es funktioniert.
Ansonsten:
Leider gibt es niemand anderen, der Interesse hat sich einer Lösung anzunehmen :/. Entweder keine Zeit (was verständlich ist) oder keine Antworen
. greetz
Sonntag, 19. Juli 2015, 22:39
Wenn ein Thema zwei Wochen lang keinen neuen Beitrag bekommt, vermerkt das Forensystem es als erledigt. Keine Sorge, nur ein Automatismus.
Ich steck gerade noch in der Prüfungsphase, aber verzage nicht! Playm bleibt an dem Problem dran!
Ich steck gerade noch in der Prüfungsphase, aber verzage nicht! Playm bleibt an dem Problem dran!
Das große Scientia Wiki zur Spielentwicklung
Was ist das RGSS ? RGSS-Dokumentation auf Sc
Kyoshiros Makerkurs
Musik von Shabraxxx für euch
Guide zu den Audioformaten
Skripte von mir (Auswahl):
Atmungssystem | Streichholzsystem | Animiert durch Bücher blättern
Random : Marktsystem für Kardor | Staterelated Battlergraphic | Hinweis auf mögliche Aktionen
SelfSwitchExpirationtimer Skript - Gameplayerweiterung für Pilzesammler und Farmspiele
Meine Skripte werden gerade hier gesammelt.
Was ist das RGSS ? RGSS-Dokumentation auf Sc
Kyoshiros Makerkurs
Musik von Shabraxxx für euch
Guide zu den Audioformaten
Skripte von mir (Auswahl):
Atmungssystem
| Streichholzsystem | Animiert durch Bücher blättern Random : Marktsystem für Kardor
| Staterelated Battlergraphic | Hinweis auf mögliche Aktionen SelfSwitchExpirationtimer Skript - Gameplayerweiterung für Pilzesammler und Farmspiele Meine Skripte werden gerade hier gesammelt.
Freitag, 24. Juli 2015, 12:09
Wenn ein Thema zwei Wochen lang keinen neuen Beitrag bekommt, vermerkt das Forensystem es als erledigt. Keine Sorge, nur ein Automatismus.
Oh ... i get it! Skynet hat wieder zugeschlagen. Ansonsten, freut mich zu hören! Werde ich so eben an anderen Baustellen arbeiten
.Andere Meinungen/Vorschläge von Usern etc. sind natürlich weiterhin gerne willkommen. Wundert mich ehrlich gesagt ein bisschen, dass es scheinbar kaum Interesse an dieser Möglichkeit von Z Levels gibt. Aber wer weiß, vllt. gibt es viele stille Leser.
greetz
Freitag, 24. Juli 2015, 12:57
Notfalldiscord: Hier klicken
-
Joseys Wuselei
-
Meine Story - Pausiert
Lust auf Abenteuer?
So richtig mit Selbstbestimmung?
Und mit was Spannendem? Zum Spielen? Ohne Schokolade?
"Eines, das mit dem leistungsstärksten Grafikchip der Welt läuft? Deiner Vorstellungskraft?"
Hier die Antwort:
Hier könnt ihr euren Lieblingschar wählen ;D
Und hier findet ihr das Minigame, das ab und an den Würfel ersetzt. -
Meine Arbeiten
Einige Ressourcen, vor allem Baby-Tiere, aber auch alle Requests, die ich erfüllt habe.
In unregelmäßigen Abständen fasse ich alles Neue, was so im Studio passiert ist, zusammen. -Pausiert-
-
Meine Fähigkeiten
Maker: XP
Pixeln: 
Mappen:
Eventen:
Scripten: 
Komponieren: -
(Mein) Autismus
Ich bin im autistischen Sprektrum-
sollte ich mich komisch verhalten, oder unhöflich wirken
(oder mich zu oft entschuldigen, unaufmerksam sein, unsicher wirken, zum zehnten Mal nachfragen, blablabla),
ist das nicht beabsichtigt.
Josey. Epicgarantie.
Nehmt das bloß nicht ernst! D: -
Meine Welt
Mein Ehemann Kain!
:*
Freund und Helfer in der Not, immer da, steht er mir mit Rat und Tat zur Seite. Meine andere Hälfte! : D
Er verdient einfach einen Platz (
) in meiner Signatur! XD
-
Mein Support
Der In-Game-Charset-Generator!
Erstelle Random-NPCs mit Charsetteilen!
Diese Spiele finde ich toll und brauchen viel mehr Aufmerksamkeit!
Bastelt mal Banner! : D
-
Meine beendeten Contests
[Pixelcontest] Rund um den Kürbis
Abstimmung
Siegerehrung
Das Wunder der Berge
Abstimmung
Siegerehrung -
Meine Contests
Ein Schreibcontest in Arbeit! : D 
-
-
Joseys Spiele
-
Endless Ending
Endless Ending
(Arbeitstitel, "ernstes Projekt")
Eine Reise durch die Wüste.
Sieben mächtige Gegenstände.
Unendlich viele Aufgaben.
Und die Götter haben die Würfel. -
Scripted Desaster
Scripted Desaster
("nicht ganz so ernstes Projekt")
Ein verfressener Idiot und ein sarkastischer Workaholic treffen in einem dunklen Wald auf einen weißes Kaninchen...
Ein Auftragskiller jagt einem Meisterdieb hinterher, wobei nicht ersichtlich ist, wer eigentlich wen jagt...
Und eine "Kristallhöhle", sowie einen "Wald ohne Wiederkehr" gibts auch.
Das bedeutet doch Spaß... -
Pokémon EV
Pokemon EV
("Zeitvertreib nebenbei - Kreatief-Helfer")
Ist nur ein Pokemonspiel mit üblicher Story und nicht so üblicher Story.
Ist inzwischen alles schonmal dagewesen. XD -
Lost Island
Harvest Moon - Lost Island
(Arbeitstitel, "Eventtechnik-Projekt")
Ist momentan mein Hauptprojekt, weil bei EE die Scripts einfach fehlen :<
Das Spiel ist ein Harvest Moon Abklatsch. XD
Felder funktionieren, Tiere auch, Grafiken sehen schon gut aus, Maps sind fast fertig. Man kann in die Miene, man kann einkaufen. Auf dem Papier ist alles schon durchgeplant, einiges muss noch umgesetzt werden.
-
-
Joseys Fortschritt
-
Endless Ending
Story: 60%
Charas: 20%
Maps: 01%
Zeichnungen: 05%
Grafiken: 30%
Scripte: 70%
Musik: 00%
...ist nicht viel, huh? ^^° -
Scripted Desaster
Story: 10%
Charas: 60%
Maps: 30%
Zeichnungen: 01%
Grafiken: 60%
Scripte: 70%
Musik: 00%
Gut Ding... -
Pokemon EV
Story: 60%
Charas: 10%
Maps: 00%
Zeichnungen: 00%
Grafiken: 80%
Scripte: 90%
Musik: 70%
Nicht ernstnehmen XD Das mache ich nur, wenn woanders nix mehr geht... -
Lost Island
Story: 100%
Charas: 10%
Maps: 90%
Zeichnungen: 00%
Grafiken: 60%
Scripte: 90%
Musik: 00%
Das macht richtig Spaß XD
-
-
Huiii
Bitte klicken Sie weiter. Hier gibt es nichts zu sehen. Nichts. Hören Sie? Nichts.
Samstag, 25. Juli 2015, 17:41
Hi
Ich habe nicht grundlos, bei der "Z Terrain Tag" Variante, genau ein "Z Terrain Tag" System ins Spiel gebracht. Terrain Tags sind ja schön und gut, nur hilft das nicht viel weiter wenn diese für Höhehunterschiede aufgebraucht werden und die markierten Tiles nicht für andere Dinge zur Verfügung stehen da Tiles nur einmal getagged werden können. Mit einem Equivalent (Z Terrain Tag) könnte man Tiles für Höhenunterschiede markieren und hätte zur selben Zeit Terrain Tags für andere Dinge/Features zur Hand. Hier noch mal Zitat von mir:
Ansonsten verstehe ich nicht so ganz, muss ich gestehen, wie dein Vorschlag in Bezug auf das zeichnen der Tiles arbeiten würde.
greetz
Gib jedem Tile, das die z-Koordinate ändern würde, ein bestimmtes Terrain-Tag. Das schließt unter Anderem Felswände etc. mit ein. Dann frage ab, wie viele Tiles mit diesem Terrain-Tag sich südlich des Spielers befinden. Sind also zwei Wand-Tiles unter dem Spieler, hat der Spieler die Höhe 2. Diese Abfrage kann ja parallel auch für jedes Event stattfinden, das eine z-Koordinate braucht.
Ich habe nicht grundlos, bei der "Z Terrain Tag" Variante, genau ein "Z Terrain Tag" System ins Spiel gebracht. Terrain Tags sind ja schön und gut, nur hilft das nicht viel weiter wenn diese für Höhehunterschiede aufgebraucht werden und die markierten Tiles nicht für andere Dinge zur Verfügung stehen da Tiles nur einmal getagged werden können. Mit einem Equivalent (Z Terrain Tag) könnte man Tiles für Höhenunterschiede markieren und hätte zur selben Zeit Terrain Tags für andere Dinge/Features zur Hand
. Hier noch mal Zitat von mir:
So you all know Terrain Tags, they are very helpfull. For this Solution we need an equivalent system for only one purpose: tagging specific Tiles with a Z level.
I know there are Scripts out there which offer unlimited Terrain Tags instead of only 7. Thats fine but we need the possibilty to give Tiles a normal Terrain Tag and another Value (or Values) at the same Time. And here comes the Z Terrain Tag System into Action.
Ansonsten verstehe ich nicht so ganz, muss ich gestehen, wie dein Vorschlag in Bezug auf das zeichnen der Tiles arbeiten würde.
greetz
Montag, 21. September 2015, 15:50
Hi,
ist das Thema noch auf deiner Liste Playm oder kann man das ganze Vorhaben begraben und ich muss einfach kürzer treten
?
Im zweiten Fall hätte ich die Bitte und den Wunsch ein Teil der Idee umzusetzen, genauer gesagt folgendes:
- Eine local Variable je Event und Player, um den Z Level Wert speichern zu können.
Zur Info: Hier gibt es wohl bereits ein Skript welches so eine Funktion genau bietet. Wäre demnach evtl. nicht mehr nötig. Aber das kann ich nicht entscheiden.
[XP] Self-Variables
- GANZ WICHTIG ... Das Z Terrain Tag System. Das bedeutet die Möglichkeit, den Tile ID's in Tilesets einen Wert zuweisen zu können (so wie Terrain Tags). Das ganze darf und soll natürlich nicht die standard Terrain Tags in irgendeiner Art und Weise "überschreiben". Oder einfacher gesagt: Eine Tile ID im Tileset sollte mehr als nur einen Wert besitzen können, so wie wenn man quasi einer Tile ID mehrere Terrain Tags gleichzeitig zuweisen könnte.
- Eine (negative) Kollisionsabfrage zwischen Events/Player bei unterschiedlichem Z Level (die entsprechende local Variable müsste im Skript definiert werden können).
Weiterhin wäre eine Abfrage beim Movement von Event/Player ganz cool wo gechecked wird, ob der Wert vom Z Terrain Tag des Tiles, auf welches sich Event/Player bewegt, übereinstimmt. Falls nicht, soll der Z Terrain Tag Wert in die local Variable von Event/Player geschrieben werden.
vielen Dank und wäre das machbar?
greetz
ist das Thema noch auf deiner Liste Playm oder kann man das ganze Vorhaben begraben und ich muss einfach kürzer treten
?Im zweiten Fall hätte ich die Bitte und den Wunsch ein Teil der Idee umzusetzen, genauer gesagt folgendes:
- Eine local Variable je Event und Player, um den Z Level Wert speichern zu können.
Zur Info: Hier gibt es wohl bereits ein Skript welches so eine Funktion genau bietet. Wäre demnach evtl. nicht mehr nötig. Aber das kann ich nicht entscheiden.
[XP] Self-Variables
- GANZ WICHTIG ... Das Z Terrain Tag System. Das bedeutet die Möglichkeit, den Tile ID's in Tilesets einen Wert zuweisen zu können (so wie Terrain Tags). Das ganze darf und soll natürlich nicht die standard Terrain Tags in irgendeiner Art und Weise "überschreiben". Oder einfacher gesagt: Eine Tile ID im Tileset sollte mehr als nur einen Wert besitzen können, so wie wenn man quasi einer Tile ID mehrere Terrain Tags gleichzeitig zuweisen könnte.
- Eine (negative) Kollisionsabfrage zwischen Events/Player bei unterschiedlichem Z Level (die entsprechende local Variable müsste im Skript definiert werden können).
Weiterhin wäre eine Abfrage beim Movement von Event/Player ganz cool wo gechecked wird, ob der Wert vom Z Terrain Tag des Tiles, auf welches sich Event/Player bewegt, übereinstimmt. Falls nicht, soll der Z Terrain Tag Wert in die local Variable von Event/Player geschrieben werden.
vielen Dank und wäre das machbar?
greetz
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »schM0ggi« (21. September 2015, 16:52)
Ähnliche Themen
-
Spiele & Konsolen »-
Wer kennt gute und realistische Filme und Spiele über Ninjas/Ninjutsu?
(16. Juni 2012, 22:54)
-
- Skript-Anfragen »
-
Gut'n Taak, der Eri mal wieder...
(24. Juni 2010, 23:53)
-
- Archiv Spielvorstellungen »
-
Vollversion: Evil Science (Portal fangame)
(25. Februar 2008, 17:18)
-
- Events & Technik »
-
Schatten erstellen
(1. Juli 2006, 23:43)
-
- RGSS 1 Probleme & Talk »
-
RGSS-Hilfe
(7. Dezember 2005, 18:07)
Verwendete Tags
