Testing release: 0.3.0-testing3

[fr1tz]

Source: http://files.wasted.ch/software/termina ... rce.tar.gz
Linux: http://files.wasted.ch/software/termina ... x32.tar.gz
Windows: http://files.wasted.ch/software/termina ... -win32.zip

What's new? -> https://github.com/fr1tz/terminal-overl ... /game/NEWS

[andrewj]

I tried the Windows package of this.

The program runs, but when I click play and then click "Go" it loads some stuff then crashes. I get a dialog saying "this program has stopped working" with no details whatsever of what may be wrong.

This is on Windows 7 Home Premium, 64-bit machine. Other 32-bit programs work, so I'd be a bit surprised if that was the reason.

Video card: Nvidia GF 315, OpenGL 3.2 compatible, updated Windows drivers a few weeks ago.

Finally gotta say that for a windows package, you should use ".txt" extension on the text files (like README, COPYRIGHT, etc) so that Windows can pick the right program to view them, and they should use Windows line endings (CR + LF), which can be done by zipping with '-l' option, otherwise they are unreadable in NOTEPAD.

[fr1tz]

The "go" button implies the crash happens when you're trying to start a server. If that's the case then I've no idea what could be wrong.
If it happens when you try to join one of the open servers then it's expected, because those are incompatible 0.2.0 servers and 0.3.0-testing3 doesn't filter them out yet.

[Julius]

ok played it a bit with fritz today, and besides the annoying chat bug under linux and some lag issues, it ran quite well.

Somehow many functions still feel unintuitive though... for example for someone new it feels rather random when you get a disk lock and there seems to be no feedback mechanism for teaching it to someone (besides the fact that the disks themselves are not something that people can easily understand by trial and error).

The charged xjump is also a cool new features, but does it really have to be a separate button? why not just charge on pressing space longer?

P.S.: what does the b.o.u.n.c.e actually do?

[fr1tz]

I agree that the disc lock rules are very unintuitive, unfortunately I've not been able to come up with better ones that don't break the game or make the discs useless.

I initially had just one button for xjump, but jumping on button release instead of button press didn't feel right for instant jumps.

The B.O.U.N.C.E. (should we rename that btw?) inverts enemies' movement vectors (and scales them a bit depending on how little impulse damper they have).

[Julius]

hmm, maybe remove the bounce as it seems like a feature of very little use? TOL has maybe too many features right now, that really confuse new players.

For the xjump, maybe disable normal jump all together?

For the disc lock, maybe the color of the targeting cross around the player could become increasingly red and start flashing when the lock is active? That way it shows a sort of progression depending on the damage you do.

[fr1tz]

BOUNCE is really fun and really important to ETH mode, may tweak it, but won't remove it.

I tried having only the charged jump, it sucks

I'm totally against making disc locks another "gradual" element. Really confusing for the player who's being targeted.

In general I'm more in favor of slicing "gradual" elements into concrete pieces. For example having the damage damper have three states: Full, Weakend, Disabled and being able to easily read the state by looking at the player.

[Julius]

hmm, ok so how *does* the targeting work right now? I was guessing that it locks when a certain minimum damage was dealt and that over time the counted damage gets removed again so that you have to build up damage against a degrading "lock-damage" counter.

The player being targeted could have a similar HUD element that gradually turns red to show their lock status, no? If enemy team damage was counted that would be also a cool gameplay element to encurage players to work together and target one player (think of the shots leaving little nano markers that allow a lock).

Regarding the jump, could it be a button combination then? some games allow a higher jump when pressing the crouch button the same time, so maybe it could work like this: initially press ctrl+space to start charging, but you can stop pressing ctrl so that the Etherboard turns off again. I think a combination of buttons if more intuitive that extra buttons, and it also allows people to easily discover features by "accident".

Last but not least, I see very little use in Bounce as you hardly ever get in such close contact with enemies, or am I still misunderstanding the functionality of it? In general there should be less functionality on separate buttons... so maybe bounce could be combined with the repell disc into a "context sensitive" shield flash on pressing the right mouse button?

[fr1tz]

hmm, ok so how *does* the targeting work right now?

The rules for getting a disc lock are almost the same as in ROTC: Direct hit with MGL (proximity explosions don't lead to locks), hit with sniper rifle, hitting with 4 of the 10 shotgun shots, damaging an enemy with a grenade (allowing for multiple locks at once).

The player being targeted could have a similar HUD element that gradually turns red to show their lock status, no? If enemy team damage was counted that would be also a cool gameplay element to encurage players to work together and target one player (think of the shots leaving little nano markers that allow a lock).

That would require a HUD element for every enemy that is currently damaging you.
There have been other suggestions for changing how disc locks work posted in IRC, but ROTC has already tried them all and none worked as well as the current (albeit somewhat arbitrary) rules.

Regarding the jump, could it be a button combination then? some games allow a higher jump when pressing the crouch button the same time, so maybe it could work like this: initially press ctrl+space to start charging, but you can stop pressing ctrl so that the Etherboard turns off again. I think a combination of buttons if more intuitive that extra buttons, and it also allows people to easily discover features by "accident".

I've experimented with all kinds of ideas. While I'm not completely happy with the current implementation, all the others either had serious flaws or were just really awkward. Also keep in mind that etherboard and xjump are not necessarily both present in every CAT loadout, so they can't depend on each other.

Last but not least, I see very little use in Bounce as you hardly ever get in such close contact with enemies, or am I still misunderstanding the functionality of it? In general there should be less functionality on separate buttons... so maybe bounce could be combined with the repell disc into a "context sensitive" shield flash on pressing the right mouse button?

The purpose of the bounce is to prevent players from easily running/etherboarding past a CAT. It doesn't currently fulfill that purpose 100% (esp. now with the xjump). The basic idea is that every CAT should present an obstacle. So if you want to go from point A to point B and there's an enemy CAT in between you have to disable it if you want to take the direct route. Imagine a circle around each unit on the minimap that basically acts as a wall to the enemy team.

[Julius]

The player being targeted could have a similar HUD element that gradually turns red to show their lock status, no? If enemy team damage was counted that would be also a cool gameplay element to encurage players to work together and target one player (think of the shots leaving little nano markers that allow a lock).

That would require a HUD element for every enemy that is currently damaging you.
There have been other suggestions for changing how disc locks work posted in IRC, but ROTC has already tried them all and none worked as well as the current (albeit somewhat arbitrary) rules.

That's why I suggested to count team damage, i.e. all shots from your team count towards the lock counter. Think of it as little targeting markers that stick to the player. Could be also used for other effects, like display on the map or overall visibility.

I am also not sure if all the experiences from ROTC still hold true, besides the fact that ROTC was evidently not very popular and we probably need to think of ways to make the entry barrier for TOL lower. Right now I especially consider the overly complex/non-intuitive and non-standard control-scheme to be one of the main obstacles.

P.S.: I also don't see why etherboard was removed from the gunner, seems really arbitrary and doesn't really change game-play significantly either. Controls and gameplay should feels more consistent and intuitive, randomly removing basic control modes from classes doesn't really help with that.

[fr1tz]

Ah I see... still not a fan of the idea of a gradual lock buildup. It's something that should happen instantly on certian events or not at all. The discs are second-level weapons exactly because I don't want them to surprise the player. Suddenly being attacked by a disc because that minigun projectile that exploded somewhere near you just happened to fill someone's "lock meter" would be very jarring imho. I think the problem can be softened by tweaking the weapon effects (for example having a direct hit with the MGL look very different from a proximity explosion and have all the effects that lead to a disc lock share some common visual element).

Removing the etherboard from the minigunner was not arbitrary and did affect gameplay in the way I wanted (as far as I could tell from what I've played). At close range a single minigunner can be dealt with somewhat, but unlike with other classes, facing even two minigunners is a no-win situation.
The purpose of the minigunner is to be a medium to large range support unit, not a close-range fighter (as it requires zero skill to do continuous damage at close range). Removing stealth made the minigunner vulnerable to sniping, but wasn't enough. Now because of the lack of an etherboard it's possible to keep your distance to minigunners.

Also the etherboard is not a basic control mode, it's a loadout module. The "finished" class selection dialog will reflect that.

[Wuzzy]

Oh, boy.
I think the GNU/Linux build is kinda unplayable and broken to me.

ETH3 has really bad rendering. https://i.imgur.com/L16fKAj.png
Looks like an extreme case of Z-fighting. It looks worse in the actual game. :/

ETH5 looks weird when I move, it looks like a subtle Z-fighting to me. Sorry, no screenshot here, I can’t capture it.

[fr1tz]

Yeah rendering is kinda broken for a couple maps, does it make it unplayable though?

[mray]

Ah I see... still not a fan of the idea of a gradual lock buildup. It's something that should happen instantly on certian events or not at all..

What about an automatic decline of the value - making it necessary to hit fast in a row. This will motivate land a second hit quickly and might result in more interesting fights.

[fr1tz]

Nope

[Julius]

You need to work on your public relation skills, e.g. dealing with fan suggestions and feedback

Besides that, what are your alternative ideas to make the disc lock more logical for players?

[fr1tz]

It's kinda tricky because the rules for disc locks were chosen based on how they effect game play, so it might be impossible to ground the rules for them in some sort of logic that actually makes them easier to understand rather than more confusing.

For example: "Projectiles implant "marker code" into an enemy on contact that the discs can use to track them."
Would not work because
- Sniper rifle doesn't fire a projectile
- While both SMG and shotgun could be seen as firing projectiles, the above explanation would mean that even a single shotgun "pellet" would lead to a disc lock, which would mean that the SMG should also be able to produce disc locks.
- Same goes for the minigun. A minigun that could produce disc locks is incredibly annoying.
- Does not explain how grenades could lead to disc locks

It might be possible to reduce all the current separate rules into one single "you get a disc lock if you do >x amount of damage at once" rule. More internally consistent but probably still not very intuitive.

[fr1tz]

You need to work on your public relation skills, e.g. dealing with fan suggestions and feedback

Hrhr

Sorry, but I didn't have time for a more elaborate reply, especially since after I explained my aversion to "gradual" locking mechanics, the suggestion was to improve a hypothetical gradual locking mechanic with another gradual element

[mray]

Something that happens "instantly on certian events or not at all" seems to surprise by definition.
A gradual build-up and its automatic decline would make it clear when you're in a danger zone. An actual lock wouldn't surprise then - a lucky/skilled hit would.
...trying to get what you're after here

[fr1tz]

I'm not against giving it a try, but I have no interest in implementing a mechanic I know *I* wouldn't like (both from the perspective of the player who tries to get a disc lock and having to deal with incoming discs). That's why I have no interest in discussing that particular idea. Especially since the idea is not fully realized. I mean just look at this one aspect: Assuming you have a "disc lock" bar on your hud that fills up when you take damage and declines over time. What exactly happens when it's full? Do you hear a beep, a "number of disc locks on you"-indicator is incremented and the bar resets to zero? If you want *me* to implement something I don't like I would need details on how exactly everything would work.

[mray]

Here is a more detailed proposition, but pretty similiar to how you described the process: (You didn't tell what it is you don't like about it)

*Attacker:*
Hurting the enemy (in some kind) will raise the lock stage.
You get a lock when all stages are complete.
A HUD indication tells you the stage of your enemies.

*Target:*
The lock stage you have regarding your enemy gets displayed in the HUD as a warning.
If more than one players do have a lock it indicates the highest lock value.

*Falloff:*
If no new stage was reached in a short time - all stages are lost.


But I can imagine there could be other ways, maybe involving the requirement to keep a player inside asight-zone for some time.
Concerning the simplification process it might be worth thinking about having a model that also works for getting locks on incoming disks.
Unrelated to the question of gradual vs. non-gradual: a clear indicator telling you about being in the lock of somebody sounds like a good idea don't you think?

[fr1tz]

Here is a more detailed proposition, but pretty similiar to how you described the process: (You didn't tell what it is you don't like about it)

What I didn't like in my example (where I was assuming Julius' idea of a player having only one lock meter to which that every CAT on the other team contributes):
- The fact that you will be constantly attacked by discs (as getting a disc lock is not a matter of skill, but just of time)
- "Wasting" a hit that would add a higher amount to the lock meter (say a direct MGL hit) on a CAT who's meter is almost full
- "Stealing" your teammates locks.

My take on this...

*Attacker:*
Hurting the enemy (in some kind) will raise the lock stage. <- how much for each weapon?
You get a lock when all stages are complete. <- nope, you get a lock if you're the one to fill the last stage, correct?
A HUD indication tells you the stage of your enemies. <- remember, from experience I say that the HUD should only be used to communicate one aspect of an enemy's state, which I think should still be reserved for health.

*Target:*
The lock stage you have regarding your enemy gets displayed in the HUD as a warning. <- how does that look like?
If more than one players do have a lock it indicates the highest lock value. <- how does that look like?

*Falloff:*
If no new stage was reached in a short time - all stages are lost. <- how short?

But I can imagine there could be other ways, maybe involving the requirement to keep a player inside asight-zone for some time
Concerning the simplification process it might be worth thinking about having a model that also works for getting locks on incoming disks..

Let me know when you have something specific

Unrelated to the question of gradual vs. non-gradual: a clear indicator telling you about being in the lock of somebody sounds like a good idea don't you think?

Absolutely. Maybe something like laser sight beams going from a CAT to all the other CATs it has currently locked. But something like that would require a lot of thought how to implement properly.

[mray]

What I didn't like in my example (where I was assuming Julius' idea of a player having only one lock meter to which that every CAT on the other team contributes):
- The fact that you will be constantly attacked by discs (as getting a disc lock is not a matter of skill, but just of time)
- "Wasting" a hit that would add a higher amount to the lock meter (say a direct MGL hit) on a CAT who's meter is almost full
- "Stealing" your teammates locks.

Oh, you got me wrong then. I'm not supporting the idea of having a common lock on players either.

*Attacker:*
Hurting the enemy (in some kind) will raise the lock stage. <- how much for each weapon?

Pretty hard to estimate. But it isn't that important, you don't need to know weapon values by heart - just keep an eye on the indicator.

You get a lock when all stages are complete. <- nope, you get a lock if you're the one to fill the last stage, correct?

As mentioned above you got me wrong.

A HUD indication tells you the stage of your enemies. <- remember, from experience I say that the HUD should only be used to communicate one aspect of an enemy's state, which I think should still be reserved for health.

If a player has no damage from you it's conform to that rule.
The current "locking" HUD breaks that rule. Why shouldn't a "lock-stage" HUD, too.

*Target:*
The lock stage you have regarding your enemy gets displayed in the HUD as a warning. <- how does that look like?
If more than one players do have a lock it indicates the highest lock value. <- how does that look like?

Why work out a mockup now? Creating any warning indicator does not pose a problem, no matter what kind.

*Falloff:*
If no new stage was reached in a short time - all stages are lost. <- how short?

Anything between 1s and 10s seems to be worth trying out right now.

[fr1tz]

- just keep an eye on the indicator.
- Why work out a mockup now? Creating any warning indicator does not pose a problem, no matter what kind.

It really does IME, because:
- It creates another element the player needs to keep track of
- The only way to keep track of it is by looking at it (unlike impulse & damage damper)
- Even if you look at it, it only tells you what the highest lock meter is. Meaning it will unpredictably fluctuate and generally be of little use to the player.

The current "locking" HUD breaks that rule. Why shouldn't a "lock-stage" HUD, too.

Because the disc lock indicator is only visible for a very short time. There's a huge difference between a short notification and something your brain needs to keep track of.
Besides, I would not mind getting rid of it.

Anything between 1s and 10s seems to be worth trying out right now.

Go for it!

Maybe there's a way to turn the team-based approach into something workable, but I'll be damned if I don't try something simpler first.
As far as the "every CAT has a separate disc lock meter for every other CAT" approach goes, I have zero faith of that working out in any
way. But if you really believe in it, maybe you can convince a programmer to implement it.

[mray]

- just keep an eye on the indicator.
- Why work out a mockup now? Creating any warning indicator does not pose a problem, no matter what kind.

It really does IME, because:
- It creates another element the player needs to keep track of
- The only way to keep track of it is by looking at it (unlike impulse & damage damper)
- Even if you look at it, it only tells you what the highest lock meter is. Meaning it will unpredictably fluctuate and generally be of little use to the player.

- You're right about turning a binary state into more values adds complexity. But the current simplicity comes with the price of a complex mechanic that one has to learn, so it remains a relevant question of what kind of complexity is preferable (binary vs. "gradual").
- Being able to indicate something - and doing so - isn't a bad thing, if the alternative is to come to conclusions via other "hints". A sound could support the indication.
- There is nothing unpredictable about knowing the highest lock stage any enemy has on you. It isn't an indication of how "safe" you are. (alos this only happens when 2 enemies ahve a lock on you)

The current "locking" HUD breaks that rule. Why shouldn't a "lock-stage" HUD, too.

Because the disc lock indicator is only visible for a very short time. There's a huge difference between a short notification and something your brain needs to keep track of.

1s - 10s was a pretty conservative guess. It was supposed to be a "very short time".
I don't imagine the gradual lock being something even remotely persistent - it should just be fast enough to force you trying to hit the trigger faster than you normally would, because time runs out.
1s-3s would be my non-conservative guess.

Maybe there's a way to turn the team-based approach into something workable, but I'll be damned if I don't try something simpler first.
As far as the "every CAT has a separate disc lock meter for every other CAT" approach goes, I have zero faith of that working out in any
way.

I never mentioned team-based any approach, you're probably taking about Julius idea.
About CAT <-> CAT disk lock meter: It's almost what we have it right now. It is just about adding milliseconds to a moment. That's all.

Think of it this way: Instead of one skilled shot it takes one lucky row to lock enemies.
that row might be two quick consecutive hits or three, in a timespan maybe even 500ms -2s!
It would certainly strengthen the idea to not want to *JUST* deal damage or kill, but to *play* more.

If you still think this is complete bullocks let's leave it there - there is more important stuff to do for me, too.