Roguelike-Diary (WIP ...)

[diceman]

Ich habe einige Ideen, wie ich die Verwaltung von Daten und Elementen noch optimieren kann, sollten Performance-Probleme ein issue werden ... momentan ist das aber nicht notwendig - Delays aufgrund multipler Berechnungen und List-Searches spürt man nur bei aktivierten Debugger (was ja auch zu erwarten war), im Non-Debugger-Mode funktionieren Bewegung und Interaktion aber nach wie vor so akkurat und fix wie eh und je.
Zum Beispiel könnte ich ein dynamisches Pointer-Array initialisieren, welches mit ReDim() nach Bedarf erweitert werden kann: jeder Pointer im Array zeigt auf einen bestimmten Actor; so wäre ein *effectPointer.ACTOR()-Array ebenso denkbar wie ein *monsterPointer.ACTOR()-Array. Und anstatt in den entsprechenden Prozeduren die gesamte Actor-Liste durchzuklappern, könnte ich nur das *monsterPointer()-Array durchlaufen, und mir nach jedem Schritt mit ChangeCurrentElement(actor(),*monsterPointer(i) ) die jeweiligen Elemente gefiltert nach Typ "nach vorne" holen.

Ich habe unten eine .exe zu Testzwecken verlinkt. Wer Lust hat, ist herzlich eingeladen, ein bißchen damit rumzuspielen und Feedback zu geben, wenn was nicht richtig funktioniert. Bitte beachtet, daß es keine richtige Dungeon-Creation-Routine gibt - der Prozess ist (noch) quick&dirty, es gibt keinen definierten Start oder Zielpunkt, die erstellten Maps funktionieren aber in 90% aller Fälle, werden halt nur nicht auf Spielbarkeit überprüft; es kann also durchaus vorkommen, daß ihr auf einem Feld startet, welches rundherum von Mauern umschlossen ist. In dem Fall einfach mit ESC schließen und neu starten; der Seed wird bei jedem Neustart geshufflet.
Es gibt auch noch keine KI für die Monster; sie sind alle friedlich, und lassen sich gerne von euch töten.

STEUERUNG
- Linksklick auf freies Feld = Bewegen
- Rechtsklick = Interaktion (Türen öffnen/schließen, Monster angreifen)
- Mauszeiger an Ränder bewegen = Map scrollen
- Leertaste drücken, bzw. Mauszeiger 0.5 Sekunden auf Spieler ruhen lassen = Viewport auf Spieler zentrieren
- ESC = Spiel beenden und Fenster schließen

Normale Monster haben 5 Lebenspunkte, Fliegende Monster 3.
Nahkampf macht 1-3 Schadenspunkte, Fernkampf immer nur 1 Schadenspunkt.

DOWNLOAD

[Mijikai]

Habs getestet

Hat spaß gemacht!
Funktioniert schon alles ganz ordentlich.

Was mir nicht ganz gefallen hat:
- Normaler Mouse-Icon wird noch angezeigt!
- Maus kann Fenster nicht verlassen/bewegen/verändern.
- Das Scrolling der Map geht mir zu schnell.
- Ein zentralisierter Spieler würde mir mehr zusagen.

[diceman]

Danke fürs Testen!

- Normaler Mouse-Icon wird noch angezeigt!

Hmm, das ist merkwürdig ... worauf hast du's getestet? Ich habe hier Windows 7 und 10, und da gibt es keinen normalen Cursor mehr, solange das Fenster im Vordergrund ist.
Hat jemand eine Idee?

- Maus kann Fenster nicht verlassen/bewegen/verändern.

Das lässt sich momentan leider nicht anders realisieren - ich arbeite mit zusätzlichen Abfragen, ob eine Maustaste noch gedrückt gehalten wird - mit den Windows-Mouse-Events kann man dagegen nur einzelne Klicks registrieren - und auf den zusätzlichen Bedienungs-Komfort, den ich dadurch gewinne, möchte ich ungern verzichten. Task-Switch funktioniert aber problemlos, dann kann man auch das Fenster verschieben.
//EDIT: Ich glaube, ich kann da was mit ReleaseMouse() basteln ... mal gucken!

- Das Scrolling der Map geht mir zu schnell.

- Ist auch kein "Scrolling" im wahre Sinne des Wortes. Der Viewport springt einfach um. Das lässt sich aber leicht beheben, in dem ich die Kamera immer nur von Tile zu Tile weiterwandern lasse, anstatt direkt zur Ziel-Koordinate. Quality-of-Life-Feature, momentan leider keine Priorität.

- Ein zentralisierter Spieler würde mir mehr zusagen.

Dadurch würde sich die maximal mögliche Sichtweite aber verringern und ich will das Spiel schon gerne um die 800x600-Auflösung herum balancen, da mein Laptop nicht mehr hergibt - hmmm; was hältst du von irgendeiner intuitiven Option, die Kamera zu koppen und wieder zu entkoppeln? Manuelles Bewegen der Ansicht mit WSAD? Das sollte kein Problem sein! Muß dazu noch sagen, daß ich die Ansicht Auflösungs-unabhängig geschrieben habe - d.h. du wirst hinterher auf jeden Fall die Freiheit haben, andere Fenstergrößen einzustellen, und die Größe des Viewports wird automatisch angepasst - da muß man dann insgesamt weniger scrollen.

[Mijikai]

- Normaler Mouse-Icon wird noch angezeigt!

Hmm, das ist merkwürdig ... worauf hast du's getestet? Ich habe hier Windows 7 und 10, und da gibt es keinen normalen Cursor mehr, solange das Fenster im Vordergrund ist.
Hat jemand eine Idee?

Habs nochmal getestet es lag nicht am Spiel!
Mein Fehler.

- Maus kann Fenster nicht verlassen/bewegen/verändern.

Das lässt sich momentan leider nicht anders realisieren - ich arbeite mit zusätzlichen Abfragen, ob eine Maustaste noch gedrückt gehalten wird - mit den Windows-Mouse-Events kann man dagegen nur einzelne Klicks registrieren - ...

Es geht :
http://www.purebasic.fr/german/viewtopi ... 43#p344843

- Ein zentralisierter Spieler würde mir mehr zusagen.

Dadurch würde sich die maximal mögliche Sichtweite aber verringern und ich will das Spiel schon gerne um die 800x600-Auflösung herum balancen, da mein Laptop nicht mehr hergibt - hmmm; was hältst du von irgendeiner intuitiven Option, die Kamera zu koppen und wieder zu entkoppeln? Manuelles Bewegen der Ansicht mit WSAD? ...

Hoert sich gut an
Oder wie wäre es den Spieler nur zu Zentralisieren wenn er steht und ansonsten in Bewegungsrichtung mit zu schwenken?

[diceman]

Oder wie wäre es den Spieler nur zu Zentralisieren wenn er steht und ansonsten in Bewegungsrichtung mit zu schwenken?

Hmm, das wird mir zu kompliziert. Das ist ein turn-based Spiel, einen wirklichen Zustand der Bewegung gibt es nicht - du stehst entweder oder machst einen Schritt aufs nächste Feld.
Und wenn's hinterher gefährlich wird, willst du eh nicht wie ein Bekloppter durch den Dungeon heizen.
Die WSAD-Variante gefällt mir aber grad ganz gut, das könnte funktionieren!

[diceman]

Wegen der "eingesperrten" Maus ...

Wie gefällt dir folgende Lösung?
Bei mir funktioniert es jedenfalls prima!



Abfrage in processInput():

Code: Alles auswählen

;Wenn kein Vollbildmodus, Maus freigeben sobald sie das Fenster verlässt...
If screen And mouseStatus = 0 And (MouseX() <= 1 Or MouseX() >=#xRes-1 Or MouseY() <= 1 Or MouseY() >=#yRes-1)
	ReleaseMouse(1)
	hideMouse = 1
	mouseStatus = 1
EndIf

Abfrage in der MainLoop:

Code: Alles auswählen

;Wenn irgendein Klick auf dem Fenster stattfindet, Spiel fortsetzen:
event = WaitWindowEvent(1)
If event = #PB_Event_LeftClick Or event = #PB_Event_RightClick
	If mouseStatus = 1
		ReleaseMouse(0)
		MouseLocate(#xRes/2,#yRes/2)
      centerCamera(0)
		hideMouse = 0
		mouseStatus = 0
	EndIf
EndIf

[Mijikai]

Wegen der "eingesperrten" Maus ...

Wie gefällt dir folgende Lösung?
...

Sieht ok aus (habs aber nicht getestet).

[diceman]

[...] (habs aber nicht getestet).

Konntest du auch noch gar nicht ... wird erst beim nächsten Test-Download, den ich bereitstelle, implementiert sein.
Ich glaube, es wird dir gefallen!
Auf jedenfall schonmal großes Dankeschön fürs konstruktive Kritik üben!
Die Punkte sind notiert, und werde ich sicherlich im Laufe der Zeit Wege finden, alles zu optimieren!
An erster Stelle meiner Prioritätenliste steht aber weiter das Rapid Prototyping; das Gerippe muß stehen, bevor es ein richtiges Spiel werden kann.
Trotzdem ist es hilfreich schon recht früh Feedback zu bekommen, wo Optimierungsbedarf besteht!

[ccode_new]

Hallo,

ich hab es auch gerade mal getestet.

Das mit dem Viewport gefällt mir persönlich eigentlich auch nicht.

Das ständige hin-und-her-gehüpfe ist irgend wie uncool.

Eine zentrierte Viewportverfolgung fände ich auch schöner:

Halt nach dieser Art: (Offset nicht mit einkalkuliert)

player_x = (view_w / 2) - (player_w / 2)
player_y = (view_h / 2) - (player_h / 2)
...
view_x = player_x - ((view_w / 2) - (player_w / 2))
view_y = player_y - ((view_h / 2) - (player_h / 2))

Naja...

Dein Problem ist das sprunghafte Setzen des Spielers incl. dem sprunghaften Setzen des ViewPort.

Wenn du echte Bewegungen zwischen dem Gitternetz hättest würde das ein schöneres View-Bewegungsbild geben.

Und die Maus sollte aber trotzdem unabhängig (der Bewegung des Players) davon den View setzen können. (wie vorhanden)

Es dürfte schon etwas knifflig werden ein gutes Maß zu finden.

[diceman]

Okay, überzeugt. Ich lasse mir was einfallen!