Ganymede Gate - Sci-fi roguelike (Alpha7)

[chiguireitor]

Interesting combination. Do you use your diagonals as "diagonal" joystick movements? or cardinal movements are mapped to diagonals on that second joy?

I use the actual diagonal directions for movement.

At first I tried mapping all 8 directions to a single joystick, but because of the nature of analogue joysticks, it was rather difficult to move without accidentally registering going down-left for instance as either just down or just left. Then I went to mapping cardinals to the dpad and diagonals to one joystick. Then both joysticks since it just felt more natural and often needed more buttons to be mapped which was more comfortable on the dpad directions.

This leaves a xbox360 or Logitech f310 as I have with full 8 way movement and a minimum of 16 usable buttons. And even more if needed by adding a "shift" function to one of the buttons. Which makes it so if I hold it down, then all the other buttons change their mapping functions as assigned.

The big hurdle to this is if menus cannot be navigated by cursor and enter keys. The secondary downside is There can be quite a few functions to try and memorize which button is programmed to do what. It can take a good bit of time to set it up intuitively.

Nice insight, i think i will be doing some coalescing of the axis movements so there's less drudgery going on when using controllers. Thanks for the input.

[akeley]

I actually play many roguelikes using keyboard mapping software like xpadder and joy2key. Infra Arcana, DoomRL, and Frozen depths for instance are quite easy to do so with their limited command set and the ability to scroll through ,enus with arrow keys and make selections with enter.

The best way I found for movement, is to separate the cardinal directions on the left joystick, and the diagonals on the right joystick. Using the dpad itself to be able to map to other functions.

Ha! Nice to see a RL vet also dabbling into forbidden arts of gamepad control. It`s true that adjusting these to older roguelikes can be a chore...especially seeing that d-pad never seems to work well enough - even decent ones seem to only work about 8-9 times per 10 tries and in a roguelike 10/10 is the only acceptable stat.

I actually tried that "joystick diagonals" method you describe some time ago - but somehow never could get really used to it (maybe because my PS3 pad`s joysticks are more sensitive than Xbox ones). I even gave up for some time and only used it with no-diagonals RLs.

There`s another way though, one I`ve been using when playing Crawl on my Nintendo DS for years (kudos to "Sasq" - an unknown hero who ported it) and somehow never occurred to me to apply it to this here scenario - up till few days ago that is. How it works: all movement is mapped to d-pad - diagonals and NSWE  - with a catch that these are assigned as "shifted". So basically you press, say, NW on the pad first - nothing happens - and then press Shift key (I use A on the pad)  -and only then the character moves.

This sounds like madness on paper, but is the best method to handle this old-as-the-hills issue. Try it, you`ll see ;) I was put off at first when I saw it on my NDS but after a short while couldn`t believe how cool it is and never looked back. Accuracy is 100% and there`s an added bonus of being bit more thoughtful with your movements - your brain has an extra nanosecond to consider if the next move is a good idea or not. I just finished adapting IVAN this way and it works like a charm.

Sorry to derail the thread a bit but hopefully maybe it`s some additional option to consider.

[chiguireitor]

I actually play many roguelikes using keyboard mapping software like xpadder and joy2key. Infra Arcana, DoomRL, and Frozen depths for instance are quite easy to do so with their limited command set and the ability to scroll through ,enus with arrow keys and make selections with enter.

The best way I found for movement, is to separate the cardinal directions on the left joystick, and the diagonals on the right joystick. Using the dpad itself to be able to map to other functions.

Ha! Nice to see a RL vet also dabbling into forbidden arts of gamepad control. It`s true that adjusting these to older roguelikes can be a chore...especially seeing that d-pad never seems to work well enough - even decent ones seem to only work about 8-9 times per 10 tries and in a roguelike 10/10 is the only acceptable stat.

I actually tried that "joystick diagonals" method you describe some time ago - but somehow never could get really used to it (maybe because my PS3 pad`s joysticks are more sensitive than Xbox ones). I even gave up for some time and only used it with no-diagonals RLs.

There`s another way though, one I`ve been using when playing Crawl on my Nintendo DS for years (kudos to "Sasq" - an unknown hero who ported it) and somehow never occurred to me to apply it to this here scenario - up till few days ago that is. How it works: all movement is mapped to d-pad - diagonals and NSWE  - with a catch that these are assigned as "shifted". So basically you press, say, NW on the pad first - nothing happens - and then press Shift key (I use A on the pad)  -and only then the character moves.

This sounds like madness on paper, but is the best method to handle this old-as-the-hills issue. Try it, you`ll see I was put off at first when I saw it on my NDS but after a short while couldn`t believe how cool it is and never looked back. Accuracy is 100% and there`s an added bonus of being bit more thoughtful with your movements - your brain has an extra nanosecond to consider if the next move is a good idea or not. I just finished adapting IVAN this way and it works like a charm.

Sorry to derail the thread a bit but hopefully maybe it`s some additional option to consider.

With the axes i was thinking of adding a dead zone where the destination cell gets highlighted, so you can see if you're, indeed, going diagonal before commiting the movement... however, that presents its own challenges, as the continued movement of the axis could mis-fire and go towards a unintentional direction.

Gamepads are hard to get right, but i'm pretty sure the final experience will be nice enough.

[Legend]

With the axes i was thinking of adding a dead zone where the destination cell gets highlighted, so you can see if you're, indeed, going diagonal before commiting the movement... however, that presents its own challenges, as the continued movement of the axis could mis-fire and go towards a unintentional direction.

Personally, I believe that the best solution would be to combine your idea with what Akeley describes. When the player moves the joystick, the corresponding tile is highlited, but no actual movement is made. When the player presses the designated "step/move" button, the player's character will then move. Once the player presses the "move" button, the direction which was designated is locked in until the "move" button is released. Therefor, if the player holds down said button, they will move continuously in the originally selected direction. And, of course, pressing the "step" button when it is within the deadzone without having the joystick being pointed in a specific direction will result in a wait/rest/search kind of command to let a turn go by without actually having to move.

[chiguireitor]

Last two weeks i've been slowly but surely making the DX frontend achieve feature parity with the open source frontend.

Namely, the sprite work is massive, compared to the relative easyness of creating weapons with just a new character on the ascii frontend. Here i started working on some weapons:



After getting them to a "good enough" state i copy them to the sprite sheet and complete the outlined on-the-floor sprite:



This process must be done for each sprite, as they need to look "complete" when on the floor but there's some Z-ordering going on in the marine's hands when in use. Then comes the trouble of picking the right colors for the weapons, because there's some hue-fighting going on with the marines' colors, and palette separation will be a must here. To make matters worse, each weapon will have around 8 variations of characteristics and about 6 colors, which are generated on the fly. Nasty.

Also i changed a little the fog representation and everything seems a lot smoother now:



The trick here is changing the magnification filter for the FOG/lighting texture to GL_LINEAR (so it becomes blurry) and then the pixels that are out of vision just slowly fade out from 1.0 (total visibility) to 0.0 (total fog). Also, the colors don't go completely grey, but rather they get a slight sepia treatment, so they feel more murky.

Began working on new enemy sprites (namely the drone and tracer, they are robots and so must seem mechanical):



They currently die and throw blood (even on the ASCII version) and leave a bloody corpse, that will be changed to more mechanical things.

The exploding barrels are in too, i'm changing the lighting of the sprites and tiles to a front left facing light (instead of the back left on the tileset) as it seems more natural from the point of view of the player, and that is causing some weirdness on the overall feeling of the game at the moment:



Animated sprites and particles are in too, with some big explosions showing their faces.



(In that image there's a bug whereas the enemies walk over walls, in reality those walls were destroyed and the tile is free to move).

Also, good part of the two weeks time, was solving a bug that came from implementing a naive mixer for the tiles. Fact was, the dropship tiles where being mixed with the floor tiles with the noisy mixing i implemented, and that wasn't very cool. Now i can switch mixing on a per-tile basis, letting the rendering engine know if it must mix or not.



(Btw, in the first gif of this post you can see the incorrect mixing of the dropship's tiles with the floor).

Last but not least, i'm trying to not kill myself in the process of making this game, so i'm trying to get to bed early, and changing a little bit eating habits... next up is getting me some excersice, which is happening to be hard to begin with :/ As a recent popular article made the rounds, dead men write no code, so edging ourselves to get the game done in the least amount of times usually is counterproductive to the process itself.