leveldesign, roomsize, auflösung

    • Konzeptfrage

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • leveldesign, roomsize, auflösung

      moin :)

      mal ein paar wenige generelle fragen zur herangehensweise bei einem spieleprojekt:
      mein projekt: sidescroller shoot´em´up mit mehreren paralax-scrollebenen

      1. um einen level zu designen, erstelle ich hierfür einen room, der genau die größe des levels hat? ich stelle mir die frage, ob diese herangehensweise nicht zu sehr memory-belastend ist, wenn ich alle objecte, tiles etc. schon zu beginn des levels erstelle und positioniere. arbeitet man hier besser mit timelines oder so? wenn ja, wie designe ich dann den level? erst mal erstellen, um die genauen positionen der objekte zu erhalten? dann roomsize wieder verkleinern und mit timern oder der timeline-funktion arbeiten, um sie an der richtigen stelle des level zu positionieren? bekäme ich dann kein problem mit outside room/outside view und instance_destroy()?

      2. ich hatte mir gestern verschiedene auflösungen auf die f-tasten programmiert, um zu checken, wie mein spiel bei verschiedenen auflösungen ausschaut. die beste auflösung für mein spiel wäre 1366*768/fullscreen. nur ist das eine relativ kleine auflösung, was sich bei höheren auflösungen natürlich negativ bemerkbar macht. objekte werden dadurch natürlich viel zu klein und ab einer auflösung von 2560 läuft das spiel auch nur noch mit 25-30 fps (?)
      legt man von vornerein also eine feste auflösung für das spiel fest und arbeitet dann besser im windowed mode?
      bei höheren auflösungen psst auch die grafik nicht mehr so ganz, da erstellte grafiker meist für eine auflösung von 1920*1080 gemacht sind. die HUD zum beispiel (score, lives, score) reicht bei höheren auflösungen nur noch bis zur bildschirmhälfte...

      tips? ideen? :)

      vielen dank im voraus!

    • Also

      zuerst einmal es gibt ja Views mit der Funktion Part in Room und View in Room

      du kannst also von AUßen also part eine höhere Auflösung festlegen und intern mit z.B 800 mal 600 arbeiten

      also View in Room 1920 mal 1080 und intern mit 1024 mal 800 .z.B dadurch wird der Fullscreen und oder Window 1920 px groß während innen alles auf 1024 skaliert ist - unter Windows wären sogar die 2500 kein Thema unter Android aber schon!

      dann kannst du die Objekte plazieren und zwar auf das ganze level hin keine Angst da frisst nix großartig Ram oder so deine Sprites werden in eine große textur gepackt und die isntancen dann per code erstellt und das sprite dann zugeteilt das braucht in der Regel sehr wenig Ram ich habe mal einen feldversuch gemacht und einen 12000 * 5000 px raum gemacht komplett voll mit Objekten und kam nicht über 47MB Ram also da braucht man sich nicht sorgen

      bau dein Room in voller Größe plaziere alles und setz dann die view entsprechend

    • du fuchs :D
      ja. so dachte ich mir das eigentlich auch, fuexline! danke dir für deine meinung.

      auflösung ist echt noch ein thema hier :( wird aber schon. zum thema resolution habe ich folgenden interessanten link:
      reddit.com/r/gamemaker/comment…n_tutorial_for_gamemaker/


      was mir im moment mehr zu schaffen macht, oder besser gesagt, ich mich noch nicht rantraue ist: arrays für mein waffensystem, damit ich per items im level verschiedene waffen einsammel kann und auch powerupen kann (wie z.b. streuschuss von 1er nach 3er nach 5er) und schussstärken.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von herr_martinelli ()

    • Wenn du noch FPS probleme hast, dann empfehle ich dir alle objekte außerhalb der view zu deaktivieren mit instance_deactivate_region/instance_activate_region. Damit wird dann die raumgröße und objektanzahl endgültig egal, weil immer nur das was am Bildschirm zu sehen ist aktiv ist, oder eben nur die Region die du aktivierst.

      ancient-pixel.com
      youtube.com/user/SebastianMerkl <<< ich freu mich über einen Besuch ;)

    • ...und den level mit einem oder mehreren .png zu erstellen würde den memory nicht sprengen?
      angenommen, mein level wäre 13440 ( 7 mal 1920 bildschirmbreite) groß. einige ebenen wie zb. der hintergrund des levels wiederholt sich bis zum ende des levels, wie die meisten scrollebenen. jetzt hinzugehen und ein 13440 breites bild zu erstellen (die einzelnen scrollebenen) scheint mir ein wenig zu groß. die bilder als tiles verwenden entlastet das ganze? die meisten ebenen könnte ich ja wiederholen lassen, nur komme ich dann zum levelende, wenn backgrounds von einer bildschirmbreite nur wiederholt werden?

      das grundgerüst für meinen sidescroller steht soweit, die demo funktioniert wirklich super. jetzt bin ich eben gerade dabei, das ganze in einen level zu integrieren. in meiner demo werden die 1-bildschirmbreiten scrollebenen nur (per tile hor.) wiederholt und per background_hspeed[0] = -scrollgeschwindigkeitswert bewegt.

    • Aku_Ryou schrieb:

      Wenn du noch FPS probleme hast, dann empfehle ich dir alle objekte außerhalb der view zu deaktivieren mit instance_deactivate_region/instance_activate_region. Damit wird dann die raumgröße und objektanzahl endgültig egal, weil immer nur das was am Bildschirm zu sehen ist aktiv ist, oder eben nur die Region die du aktivierst.


      wann und wo deaktiviere/aktiviere ich denn die objekte? vorallem: wenn ich sie im level platziere, wie starte ich sie zur richtigen zeit? bisher hatte ich das mit timelines gelöst. wenn der level jetzt aber größer wird, wird mir das mit timelines zu stressig...

    • er meint folgendes,

      du kannst den objekten jeweils sagen das wenn sie outside view 0 1,2,3 usw sind sie sich zerstören sollen , bei sprites und objekten die sich aber wiederholen wie zb ein Steinwürfen zum drauf laufen ist das wirklich egal weil dieses sprite bereits im Ram liegt und lediglich das createn minimal cpu Zeit kostet das ist aber alles


      mehr ram fressen da shader der schlecht programmierte Schleißfen und loops sowie so lustige Sachen wie ein schwarzes alpha 0,5 Viereck über die View zu zeichnen und lichtkegel als kreis reinzuschneiden weil man nicht mit partikel umgehen kann


      Unter WIndows ist es eigentlich fast eh egal n kleiner Dual Core mit Onboard Graka die DX9 kann und 512MB freien Ram läuft alles in der Regel Butterweich wenns vernünftig gemacht ist.

      Android ist da wesentlich undankbarer

      ein 1.6Ghz Quadcore ist eben nicht so schnell wie ein Core2Quad mit 1,6Ghz Arm ist wesentlich schwächer in der Realleistung - ein 1.6Ghz arm v7 billig prozessor ist so schnell wie ein pentium 3 mit 633Mhz Realleistung, ne GPU ist da schon eher eine Referenz da Android ja open GL benutzt kann man ne mali 400 welche am weitesten in den billig geräten verbreitet ist als Gforce 3 sehen

      im prinzip muss man n Android Handy als alten Pc betrachten und dementsprechend Ressourcenschonend arbeiten, wenn man aber nur für High End Smartphones was machen will darf man durchaus die leistungswerte eines kleinen intel dual core pcs veranschlagen

    • fuexline schrieb:

      er meint folgendes,

      du kannst den objekten jeweils sagen das wenn sie outside view 0 1,2,3 usw sind sie sich zerstören sollen , bei sprites und objekten die sich aber wiederholen wie zb ein Steinwürfen zum drauf laufen ist das wirklich egal weil dieses sprite bereits im Ram liegt und lediglich das createn minimal cpu Zeit kostet das ist aber alles


      mehr ram fressen da shader der schlecht programmierte Schleißfen und loops sowie so lustige Sachen wie ein schwarzes alpha 0,5 Viereck über die View zu zeichnen und lichtkegel als kreis reinzuschneiden weil man nicht mit partikel umgehen kann


      Unter WIndows ist es eigentlich fast eh egal n kleiner Dual Core mit Onboard Graka die DX9 kann und 512MB freien Ram läuft alles in der Regel Butterweich wenns vernünftig gemacht ist



      das habe ich schon verstanden ;)
      mir war nur gerade nicht ganz klar, wo ich das alles aktiviere/deaktiviere. wenn ich jetzt z.b. einen gegner im room positioniere, kann ich dort ja nicht das objekt aktivieren, reaktivieren. das muss also in meinem code passieren. logisch. wäre es dann sinniger, gleich im code die gegner per draw_sprite zu positionieren, anstatt sie im room einfach nur "hinzuklicken"?

      wo kommt der schlauch denn da her, auf dem ich gerade stehe? :D

    • dein gegner ist ja ein Objekt du kannst ihn nach dem Tot zerstören oder sobald er aus der view ist, wenn er wieder in der view kannst du ihn wieder mit snstance create herholen, oder wenn der held an einem gewissen Platz kommt den held vorher schon neben der view wieder spawnen lassen

      das würde ich aber nur bei Gegnern usw anwenden nicht bei essentiellen level bestandteilen wie Boden usw denn das im nachinen createn frisst mehr Power als das vorher im Room vorgeben

    • fuexline schrieb:

      dein gegner ist ja ein Objekt du kannst ihn nach dem Tot zerstören oder sobald er aus der view ist, wenn er wieder in der view kannst du ihn wieder mit snstance create herholen, oder wenn der held an einem gewissen Platz kommt den held vorher schon neben der view wieder spawnen lassen

      das würde ich aber nur bei Gegnern usw anwenden nicht bei essentiellen level bestandteilen wie Boden usw denn das im nachinen createn frisst mehr Power als das vorher im Room vorgeben


      das passiert in meiner demo schon alles, fuexline. ich bin gerade im wechsel von grundgerüßt-demo nach richtigem level.
      meine demo hat (bis auf mein waffensystem) alles, was ein level braucht.

      ship fliegt, schießt, wird "verwundet", explodiert mit wunderschöner anim, besitzt leben, health, speed, respawnt nach verlust eines lebens
      gegner fliegen per path, schießen auf ship, haben hitpoint, machen punkte für den player durch tod und wunderschöner explosion ;)
      HUD existiert mit leben(durch sprites dargestellt), healthbar, punkteanzeige
      7 verschiedene scrollebenen stellen den level dar. alles als einzelne .png, die per tile.hor in den roomeinstellungen wiederholt werden.
      musik und soundeffekte habe ich auch schon erstellt...

      nun gilt es, eine ganze welt darauf zu erstellen...

      kennt ja jemand ein tutorial, das sich mit sidescroller shoot´em´up sinnvoll beschäftigt? mit levelaufbau?
      oder kennt sich hier wer damit aus und kann mir einzelne schritte und die herangehensweise beschreiben?

      wie gesagt, sieht meine demo ja schon aus, wie ein level. nur komme ich ja nie zum levelende, wenn die scrollebenen bloß in einer do-loop-schleife scrollen. da hat ein level ja... sagen wir mal... 10 jahre spielespass :D

    • achsoo du willst so ein Weltraum Shooter machen na ja du hast zwei Möglichkeiten!

      1. du baust eine bedingung ein die das level beendet aka wenn step == x , wenn 500 gegner = erledigt sind wenn Boss = erledigt ist hört das LV auf zu Scrollen und End Animation passiert

      2. du baust das level komplett auf sprich nen Raum 20000 mal 800 plazierst dort alles und gut ist

    • fuexline schrieb:

      achsoo du willst so ein Weltraum Shooter machen na ja du hast zwei Möglichkeiten!

      1. du baust eine bedingung ein die das level beendet aka wenn step == x , wenn 500 gegner = erledigt sind wenn Boss = erledigt ist hört das LV auf zu Scrollen und End Animation passiert

      2. du baust das level komplett auf sprich nen Raum 20000 mal 800 plazierst dort alles und gut ist



      siehste? soooo wird ein schuh draus. oder besser gesagt: ein schuhter :D

      dann komme ich der sache schon näher!

      beispiel:

      if step = 1432
      {
      mach mal ein sprite dahin;
      }

      oder

      if step = 13440
      {
      hör auf zu scrollen, der level ist am schluss angekommen;
      mach den endgegner da hin;
      }

      right?

      wobei ich step als befehl nicht habe/finde. ich benutze game maker studio pro

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von herr_martinelli ()

    • also dein Roomspeed wird vermutlich 60 sein, dann wird pro Sekunde dein Step 60 sein wenn du also 5 min rumfliegen willst bevor es zuende geht kannst du also

      im step event ne variable ++, bedeutet die variable nimmt pro Sekunde den Wert 60 an
      bedeutet 60 mal 60 wären eine minute bzw 300*60 wären 5 min was dann 18 000 wären

      oder du machst es anhand der Gegner fest jeder Gegner bringt ein enemy++ wenn Gegner bzw enemy == 10 sind kommen 10 neue gegner wenn enemy == 500 ist dann lv ende oder boss

    • würde ++ statt +=1 nehmen habe gemerkt das HTML5 das nicht mag und webGL dann durchtillt

      ja die LV Time kannste so drawen du kannst aber das so nutzen um eben von zeit zu Zeit events einzufügen drawen müsstest du es btw nicht im BG laufen lassen reicht schon

      Man könnte auch nen Alarm nehmen und den auf X steps stellen und die aktuelle zeit abfragen ist eigentlich fast das selbe btw

    • fuexline schrieb:

      würde ++ statt +=1 nehmen habe gemerkt das HTML5 das nicht mag und webGL dann durchtillt

      ja die LV Time kannste so drawen du kannst aber das so nutzen um eben von zeit zu Zeit events einzufügen drawen müsstest du es btw nicht im BG laufen lassen reicht schon

      Man könnte auch nen Alarm nehmen und den auf X steps stellen und die aktuelle zeit abfragen ist eigentlich fast das selbe btw


      ne. mit der variable geht das schon ganz gut so. wird mir schön angezeigt und ich kann den level damit bauen. ist aber auch nix anderes, wie mit der timelinefunktion zu arbeiten. aber durch die variable, die übrigens global sein sollte ;) habe ich die werte, die ich wissen muss, wann in der timeline ein objekt erstellt werden soll...

      soweit mal dankeschön!

      sie werden von mir hören ^^

    • fuexline schrieb:

      er meint folgendes,

      du kannst den objekten jeweils sagen das wenn sie outside view 0 1,2,3 usw sind sie sich zerstören sollen , bei sprites und objekten die sich aber wiederholen wie zb ein Steinwürfen zum drauf laufen ist das wirklich egal weil dieses sprite bereits im Ram liegt und lediglich das createn minimal cpu Zeit kostet das ist aber alles


      mehr ram fressen da shader der schlecht programmierte Schleißfen und loops sowie so lustige Sachen wie ein schwarzes alpha 0,5 Viereck über die View zu zeichnen und lichtkegel als kreis reinzuschneiden weil man nicht mit partikel umgehen kann


      Unter WIndows ist es eigentlich fast eh egal n kleiner Dual Core mit Onboard Graka die DX9 kann und 512MB freien Ram läuft alles in der Regel Butterweich wenns vernünftig gemacht ist.

      Android ist da wesentlich undankbarer

      ein 1.6Ghz Quadcore ist eben nicht so schnell wie ein Core2Quad mit 1,6Ghz Arm ist wesentlich schwächer in der Realleistung - ein 1.6Ghz arm v7 billig prozessor ist so schnell wie ein pentium 3 mit 633Mhz Realleistung, ne GPU ist da schon eher eine Referenz da Android ja open GL benutzt kann man ne mali 400 welche am weitesten in den billig geräten verbreitet ist als Gforce 3 sehen

      im prinzip muss man n Android Handy als alten Pc betrachten und dementsprechend Ressourcenschonend arbeiten, wenn man aber nur für High End Smartphones was machen will darf man durchaus die leistungswerte eines kleinen intel dual core pcs veranschlagen


      Das mein ich nicht^^

      Mit instance_activate/deactivate werden die objekte nicht zerstört sondern sie werden nicht mehr berechnet, somit hast du nicht hunderte objekte an denen du schon vorbeigeflogen bist oder welche die du noch nicht erreicht hast,aber für die schon die ganze Zeit das step und draw event aufgerufen wird und dir rechenpower unnötig wegfressen. Du hast nurmehr pointer auf die objekte im speicher und wenn du sie dann aktivierst weil sie in deiner nähe sind werden erst die sprites gezeichent usw. Dh ist ihm dann der Boss am Ende des Levels solange wurscht bist du ihm tatsächlich gegenüberstehst.

      Aber wie gesagt, wenn es momentan keine Probleme mit den FPS gibt dann brauchst du nix aktivieren oder deaktivieren, es ist nur ein kleiner performance kniff.

      Wenn du große Hintergründa hast, dann schau, dass du sie in so kleine selbstähnliche Teile wie möglich zerlegen kannst, Tiles draus machst und aus diesen Bausteinen dann das Level aufbaust, bevor du 10 riesige pngs hast die sich nur minimal unterscheiden. Ziegelwand, Fenster, Dachteil etc. Denn wenn du so große Bilder hast muss der GM sehr oft zwischen den einzelenen Texturepages wechseln und das frisst auch wieder FPS. Alle Sprites die glieichzeitig zu sehen sind sollten nach möglichkeit auf einer oder nur wenigen texturepage verteilt sein, das ist am performantesten. Die Größe der texturepages kansnt du in den global gamesettings einstellen und sie dir auch anzeigen lassen.
      Basically, all pixel-based graphics (sprites, backgrounds) are stored in texture pages. On some systems, the game temporarily freezes (we're talking a fraction of a second, in most cases) while loading a new texture page.
      Depending on the size of your texture groups, you can have multiple groups on one page, or a single group can be spread along multiple pages.
      Your goal is to limit the number of pages that need to be loaded per room. For instance, if you have a set of graphics that only appear on the main menu, set them to a "menu" group. Set your in-game graphics to a "game" group.
      When GM enters the Main Menu room, it loads the Main Menu graphics, pulling up the page with the "menu" group graphics. Then when you start the game, the code should leave the menu room, clear virtual memory, and start the in-game room. GM will then try to load the page containing the "game" group graphics.
      Again, if you have few enough graphics, everything will be on one page anyway, so it really won't make that much of a difference. However, if you have a lot of graphics, trying to split groups up by sections helps to keep most, if not all, load times to when the room starts, preventing unintentional pauses in play.

      ancient-pixel.com
      youtube.com/user/SebastianMerkl <<< ich freu mich über einen Besuch ;)

    • dann könnte ich mir aber die viele schreibarbeit sparen und per timer einfach einzelne timelines aufrufen...

      GML-Quellcode

      1. //create event
      3. global.leveltime = 0;


      GML-Quellcode

      1. //step event
      3. global.leveltime ++;
      5. if global.leveltime = 1000
      6. {
      7. instance_create(1200,649,obj_fighter);
      8. path_start(path_fighter_formation1,4,path_action_stop,1);
      9. }



      meine gegner im room per klick zu positionieren, wäre einfacher. nur: starte ich dann einfach nur bei z.b. leveltimer = 2000 eine timeline, in der nur steht, wie der gegner sich bewegen soll? so war das eigentlich angedacht, wie ich meine level gestalte. finde ich den besseren weg, da man im room einen genauen überblick über den level hat. nach dem positionieren erst mal alle deaktivieren und wenns zeit ist, per path losfliegen lassen? wenn ich sie per klick im room positioniere, scrollen sie ja nicht mit. also muss da eine abfrage her, ob der player in der nähe ist und dann einen code, dass sich der gegner in bewegung setzt?

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von herr_martinelli ()