Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Gobbopathe]

As you mentioned in An Interesting Discovery About Speed in the General Discussion section

A couple other things I noticed (not 100% sure):
The waiting action appears to wait until the beginning of the next turn and not wait for 100 time units. I'm not sure if this is intended or not, but it is unclear in controls/documentation.

Enemy robots appear to only perform actions at the beginning of turns and not during turns, like the player can. (might be linked to the movement time issue above)

Yeah, this must be an illusory side-effect of the newly discovered one-turn movement issue, since most non-movement actions are intended to take exactly one turn. Robots follow the exact same rules as the player regarding time--the time system just puts everyone in a queue and pushes them back by X time every action they take. There is in fact no relation to the game turns counter at all--the "turn counter" itself is shifted around within that same queue as necessary, always being pushed back by 100 units every time its own "turn" comes around .

Waiting simply pushes the player back in the queue by 100 units, behaving as an action that costs 100 time, so in game turns it could theoretically put you at the beginning, or the end, of the next "turn," but no matter what it will be somewhere in the next turn where you end up.

As you can see, turns are really just a convenient way to talk about the passage of time, but not super strict (with regards to robots) except when talking about effects and events that are intended to happen on a per-turn basis.

When meeting some robots we do often duck back into a better position and wait for them here. One or several turns = 100 time units. It means for instance I hid myself at time 1090, and waited let's say until 1390 (3 full turns), until I notice a walking robot on the threshold. But maybe he's arrived at time 1300, and "lost" 90 unit times "for no reason" before I could play. I will shoot a volley, and he will play at 1400.

My suggestion here would be to implement an overwatch stance (not sure of the english term in the tactical games, I think it is understandable). Instead of the "wait" action, it would be "fire a volley as soon as you see an enemy".
Of course I see it would not be that easy. For instance, what if a robot comes in through a secret door I did not notice ? Or if it is not the robot I was waiting for ? Maybe then it would need to ask the player for a confirmation when the situation occurs (see a new robot). Well that would lengthen the game inappropriately.  Or to simplify, the rule could be :
- if the player waits when no enemy robot is visible, then wait 100 time units OR until an enemy shows up before 100 time units (and maybe display a message in the log to emphasize Cogmind waited shorter than 100 because he noticed [Robot Name]
- if the player waits when an enemy is visible, then wait 100 time units OR until other enemies show up before 100 time units (with the same kind of message)

Well since your roguelike turns out to be quite tactical, to say the less, did you think about that kind of gameplay mechanic ?

Thanks

[Kyzrati]

"Overwatch" would be a correct term. (Or did you mean "stance"? A more generic and widely applicable term would be "state," but "stance" works for humanoid etc. subjects.)

That's a good idea in that it's true you do often set up to ambush incoming enemies. And Cogmind is certainly a highly tactical roguelike (I've wanted to write a blog post about that very topic for some time), so that kind of mechanic wouldn't seem so out of place.

Automatically firing on an enemy would present too many complications as you indicate, but your alternative solutions are quite elegant! I like both rules. While at best they can only save you a fraction of a turn, they can be applied entirely automatically and require no changes to the interface or player feedback. Basically it just ensures that the player doesn't waste any time unnecessarily, which is entirely logical given the situation.

The game already tracks how many hostiles are in view; the main change necessary would be to relocate you next in the queue as soon as a new enemy enters your FOV. I'll look into it later

[Gobbopathe]

Automatically firing on an enemy would present too many complications as you indicate, but your alternative solutions are quite elegant! I like both rules. While at best they can only save you a fraction of a turn, they can be applied entirely automatically and require no changes to the interface or player feedback. Basically it just ensures that the player doesn't waste any time unnecessarily, which is entirely logical given the situation.

The game already tracks how many hostiles are in view; the main change necessary would be to relocate you next in the queue as soon as a new enemy enters your FOV. I'll look into it later

Thanks ! I am looking forward to reading you about it !

[zxc]

The alternative solution (flexible wait delays) is also an idea I've had. This 'waiting overkill' issue exists in many turn-based games, including DCSS, where if truly necessary I would swing a faster than 1.0 delay weapon instead of resting a turn. I think coming up with a solution in Cogmind is more important than most other games though, since losing a bit of time is almost never meaningful in DCSS but it could mean the loss of components in Cogmind.

[Gobbopathe]

Right, and as you notice even in DCSS this feature does not exist, you have to emulate it yourself by swinging in the air to get a delay < 1.0

[Adraius]

I'd just like to chip in with my own support for this feature.  It both allows you to be more time-efficient, and ensures you don't accidentally skip forward too far with the mouse-wheel while waiting for an enemy to round a corner and get yourself unintentionally shot.

Essentially, on it's turn, Cogmind does nothing, but sets itself in a state to immediately act after a trigger - the trigger being any hostile entity entering Cogmind's LOS, or Cogmind taking damage (from a Hunter shooting through a wall, for example).  Ideally, this state would have modifiers in the options allowing the player to define the length of this state (1-10 game turns?) and options to disallow Scouts from triggering the interrupt or allow it to trigger on the appearance of Scavengers (useful when I'm repairing Storage Units - I pile all the items in a corner, then wait out the repair duration crouched in the middle of the pile like a brood mother, playing Scavenger Tower Defense until the repair is done).  I realize this may be adding more complexity than is ideal to a niche feature like this, but I unless you decide against adding 'Overwatch' at all, it's better to add a fully-featured one than best suits the players' needs than a bare-bones one that isn't player configurable.

If something triggers this state, Cogmind leaves its previous position in the 'initiative order' and is inserted immediately after the triggering unit.  This still means that fast units like Swarmers will be able to get through and fire before Cogmind can act, but I think that is a perfectly acceptable advantage for high-speed units.

[Reiver]

Simplest solution: It ticks over until the first new robot shows up, then goes back to the usual idling.

In a busy hall this might be a little annoying perhaps, but you could have an option to ignore the neutrals for when they don't bother you. Personally, I appreciate the warning. Bloody scavengers...

[Gobbopathe]

Hi, since you've made huge progress since the alpha versions I played, I decided to take some time to play again, and I have a very long time discovering it again. But I am a bit stubborn , and I was wondering if you implemented this "overwatch" feature ? Ctrl+F "overwatch" does not return anything in your changelogs. As we've discussed above I would consider it very interesting.
I will read it thoroughly to admire all the wonders waiting for me in my next games.
Best wishes for the end of your work, be confident that's great !

[Kyzrati]

Hey Gobbopathe, welcome back. Definitely a ton of improvements and new features out there. In relation to this thread in particular, I didn't call it "overwatch," and it won't shoot automatically, but it's now possible to, once you're in a defensible position, hold the wait key and it will automatically block your waiting as soon as an enemy comes into view. It's not a perfect system, but it works pretty well for at least those enemies who don't move very fast (i.e. stuff other than Swarmers). I could further improve it eventually, but for now it's satisfactory.

[Gobbopathe]

Great ! I think we both agreed that it was not a good idead to shoot automatically. So when you write it will block the waiting as soon as the enemy comes into view, it looks like exactly the rules I have suggested.

- if the player waits when no enemy robot is visible, then wait 100 time units OR until an enemy shows up before 100 time units (and maybe display a message in the log to emphasize Cogmind waited shorter than 100 because he noticed [Robot Name]
- if the player waits when an enemy is visible, then wait 100 time units OR until other enemies show up before 100 time units (with the same kind of message)

I have just finished read it all. It will take time to digest all those information -5 for my first run, was a bit unexpected, I guess I was really lucky there. I stop polluting this thread, thanks a lot for your quick answer

[zxc]

I don't think it works quite like what you're saying Gobbopathe. By holding the wait key, you are wasting 100 time units at a time, and as soon as an enemy enters view after the 100 time units have passed, it will block further waiting. If the enemy entered your view after just 10 time units instead of 100, then it will be 90 time units closer to its next action.

[Kyzrati]

This is why there's a rather big difference between fast and slow enemies here (which I kinda like as it makes some sense!). Most enemies require more than 100 time to move, thus when they come into view they'll have at least a turn or more of time to wait. That said, the dynamic has somewhat changed since we modified waiting to draw down 100 time rather than zero your remaining time--this feature is no longer quite as effective. (And the 100-time-to-wait hasn't even fully solved the issue of peeking...)