This thread contains the table of races which I skipped when adding codriver checkpoints.
It will be continuously updated and the title will change accordingly.
N NAME LOCATION REASON
--------------------------------------------------------------------------------------------------
1. Chasing Shadows: Old Quarry /events/chasing/oldquarry/ no road
2. Coy Goblet: Borderline /events/coy/borderline/ too much road
3. High Stakes: Endless options /events/highstakes/endless/ too much road
4. Marathon: Back Again /events/marathon/marathon/ too much road; too complex
5. Marathon: Beyond Roads /events/marathon/marathon/ too much road; too complex
6. Marathon: Marathon /events/marathon/marathon/ too much road; too complex
7. Marathon: Midnight Endeavor /events/marathon/marathon/ too much road; too complex
8. Marathon: Wet Ponds /events/marathon/marathon/ too much road; too complex
9. Picturesque Tournament: Riddle /events/picturesque/riddle/ too much road
10. Weird Dare: China /events/weird/china/ no road
11. Weird Dare: Frisky Hills /events/weird/frisky/ too much road
12. Western Challenge: Great Plains /events/westernchallenge/greatplains/ too complex
13. Western Challenge: Rocky Prairie /events/westernchallenge/rockyprairie/ too complex; no clear way
14. Western Challenge: White Sands /events/westernchallenge/whitesands/ too complex
15. Ancient /maps/ancient/ no road
16. Country Road /maps/country/ too complex
17. Cracks /maps/cracks/ too much road
18. Delta /maps/delta/ undriveable terrain
19. Forced Caution /maps/forced/ missing SVG file
20. Foreign /maps/foreign/ too complex
21. Ghats /maps/ghats/ too complex
22. Mountain Pass /maps/mountainpass/ undriveable terrain
23. Mudbath /maps/mudbath/ missing SVG file; too complex
24. Pathfinder /maps/pathfinder/ too much road
25. Rugged /maps/rugged/ too much road; too complex
26. Serpentine /maps/serpentine/ undriveable terrain
27. Snowy Hills /maps/snowyhills/ undriveable terrain; no clear way
28. Steep /maps/steep/ missing SVG file
29. Tea in the Sahara /maps/tea/ road too wide
30. Tropic Island /maps/tropic/ too complex
31. Vital Turn /maps/vital/ too complex; no clear way
32. Wood Trail /maps/woodtrail/ missing SVG file; too complex
EDIT: apparently, the title cannot be changed.
Last edit: Andrei 2016-01-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Today I added codriver notes to "Old Quarry". Mainly beacuse it felt rather random if the car went from firm sand to loose sand without any texture indication I added some brightness difference between the road and the surrounding terrain.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I noticed that the terms "opening" and "closing" would be handy and something like "up" and "down" might be of value too for possible future enhancements of the codriver word set.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I noticed that the terms "opening" and "closing" would be handy and something like "up" and "down" might be of value too for possible future enhancements of the codriver word set.
Yes, many words and expressions could be added to improve the codriver notes. With inspiration from real pacenotes we could add "fast", "hook" and "K" curves, "keep right/left/middle", "tightens/opens into...", "over crest", "over dip" and so on.
Adding new codriver words in the game code is very easy: only the file /src/include/codrivervoice.h needs to be edited, then the rebuilt game will load the corresponding .WAV files at initialization. The hard work is actually recording the voice such that it sounds good.
However for now let's use only what we have, otherwise 0.6.3 will never be finished, or at least not while I'm still active.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now that you have hidden the codriver circles I experience what I was afraid of all along: If I drift off the road on the wrong position far enough and drive back to it later I do not get any more codriver commands and it's totally unclear for the player why this happens. It feels like a bug.
In my opinion it is definetly safer to disable the cronical order of the codriver commands. It should be enough to pass through the normal checkpoints in the given order.
The only other sensible option I see is making the codriver checkpoints visible too. But this looks rather messy ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In my opinion it is definetly safer to disable the cronical order of the codriver commands. It should be enough to pass through the normal checkpoints in the given order.
Yes, but this doesn't work for maps containing loops. Are you willing to do these edits yourself? Or shall we start from opposing ends?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Right now I am working on the credits. It seems we will have issues with the co driver notes in every case as soon as someone fails to follow the instructions closely enough since it would be easy to get at least one wrong command when driving in the wrong direction before realising that something went wrong because the driver is hearing no more codriver notes.
The only thing popping into my mind is to add insanely many invisible checkpoints in order to keep track of where the car is going. If the car then leaves the checkpointed area we could give out a warning like: "you left the racing path" and if the checkpoints are passed in the wrong order we could do an other warning: "you are driving in the wrong direction". (See attached image "tracking.png" for reference.)
This way we could use just one array of checkpoints with optional attributes like "visible" and "[a random codriver command]".
But thinking about this I guess it would be much easier to just add an other black and white image where one value indicates the route and the other tells your script to warn the driver since he/she left the racing route. In practice this would mean to just provide an image with a much wider road. (See attached "tracking2.png".)
Would you know how to implement this? Since you managed to do wonders with the terrain map I guess this would be easy for you to do.
Either way: For the future I would prefer to not use two seperate checkpoint sets, but to have only one array of ceckpoints with different atributes for the needed functions.
You are right that a black-white roadmap would be much easier than adding many "invisible" checkpoints by hand. However we've already been through the hell of updating maps once: and personally, I'm not willing to spend my days adding B&W roadmap textures.
Anyway, I'll add this suggestion to my To-Do list for 0.6.4.
Either way: For the future I would prefer to not use two seperate checkpoint sets, but to have only one array of ceckpoints with different atributes for the needed functions.
I think this can be done relatively easily, but I believe this is a bad idea. Nonetheless I shall add it to the To-Do list for 0.6.4 and it will be implemented in a fully backward-compatible fashion so that other map designers can still use separate checkpoint lists.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
and personally, I'm not willing to spend my days adding B&W roadmap textures.
Certainly not for this release, but I would be willing to add such images later on since I think they could be done rather fast and it would be great to get warned if the car gets to far off the supposed track.
but I believe this is a bad idea.
Why?
At the moment we deal with two sets of checkpoints. I think this is much more complicated than necessary since most visible checkpoints could be placed where we would want codriver checkpoints anyway. The process would then be to just make some codriver points visible too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have just seen your commit with the codriver symbols. You concat seperate words into phrases and use images for that. This is elegant, but leads to problems where I used the words in an other order. Especially in Marathon there are so many curves following afer another that I used something like "left chicane" istead of "chicane left" because I wanted to give most important information in which direction the next curve will go as fast as possible. I figured this gives the driver a little more headstart in such situations.
I guess I have to redo Marathon now.
And I will try to offer some cooler icons too. Especially challenging are clear icons for different soil materials ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Gut feeling. The current way of doing things is at least simple and straightforward. The proposed new way could result in unmanageable checkpoint salads. But maybe my intuition misleads me.
I guess I have to redo Marathon now.
That's unfortunate, I hope it won't take you too much time. Theoretically this problem can be "fixed" by simply adding new textures named "LeftChicane.png" and "RightChicane.png". However I am against that because it might break other maps randomly. After all, it's "Marathon" that needs to be fixed, not the other maps.
And I will try to offer some cooler icons too. Especially challenging are clear icons for different soil materials ...
I am interested to see what you come up with, although I have to admit I'm quite pleased with the current arrow style (but not with the drawings themselves of course).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The proposed new way could result in unmanageable checkpoint salads.
I argue the opposite since I find it hard to manage right now: We have two totally independent sets of checkpoints which need to be synchronized cerefully in order to work properly. This is a source for potential errors. With my proposal there would be just one set of checkpoints and some of them would just carry a "visible" flag. The only functionality we would loose there is the possibility to have codriver notes for different routes. But you argued that this doesn't a true rally anyway and we just tried it once with "frozen" as far as I can remember.
After all, it's "Marathon" that needs to be fixed, not the other maps.
Unfortunately I don't think this is totally true. But still, for sure it is less work to adapt those cases than all maps. or the basic concept.
I'm quite pleased with the current arrow style
Yes, I too think you did a good job there. I only feel the thin lines don't stand out enough. I will try to do something that looks more like the arrow buttons from the menu. So I will try to use thicker strokes for example.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Let's try to remain disciplined and stick to the above formula, otherwise all our codriver work may start unraveling.
And about the arrow signs, one mistake I have made (which I can't fix) is that their bases are not aligned at the same height. That was not intentional, although the lack of horizontal centering was.
Edit: nevermind the excessive edits to this post, I was having fun with the formula.
Last edit: Andrei 2016-01-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately so far I didn't know there was a formular. Therefore I guess I will need to change a lot in basically all the maps I did the codriver notes for.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately so far I didn't know there was a formular. Therefore I guess I will need to change a lot in basically all the maps I did the codriver notes for.
This was a failure to communicate on my part, sorry. Even though I coded the codriver notes to work regardless of word order, I had a specific structure in mind which I thought would be self-evident.
That said, I'd like to know in what ways your notes deviate from the above formula.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd like to know in what ways your notes deviate from the above formula.
Since I didn't consider the order fixed I often used things like "left hard chicane" for example. Now I understand this should have been: "chicane left". And a chicane can't be "hard" according to this concept. It would be bad usability to make more symbols since they need to be very clear at first glance to be useful at all.
I just wanted to provide the most important information first. If I don't listen carefully or can't concentrate on listening, I would want to get the most basic information instantly. In my opinion the direction of the next curve is the most important. Only after getting that I probably want more detail like "chicane" oder "hairpin". Of course this doesn't matter if I can have the notes early enough but especially on maps like Marathon there is almost never any time between curves.
And it doesn't help to have more than two or maximum three commands connected via "into" since in practice this is to much information at once - at least for me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In my opinion the direction of the next curve is the most important. Only after getting that I probably want more detail like "chicane" oder "hairpin".
Every rally crew has their own style. Some use words for corner severity, some of them use numbers. Most of them seem to use severity+direction. If we try to build all that into Trigger Rally we'll waste a lot of time adding something of little value. So let's just stick to what we have...
And it doesn't help to have more than two or maximum three commands connected via "into" since in practice this is to much information at once - at least for me.
Now that I've added codriver signs the codriver voice isn't as important to listen to, so there's that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If we try to build all that into Trigger Rally we'll waste a lot of time adding something of little value.
I didn't want to convince you. I just explained my line of thinking because you asked me to. I'm fine with the approach you went for. Unfortunately I didn't understand it in time.
Now that I've added codriver signs the codriver voice isn't as important to listen to, so there's that.
I don't think having many symbols after each other will be much different.
I can't think of a way to incorporate the "long"-attribute in a self-evident way. The "+"-symbol doesn't really work for me.
I would prefer to indicate the "cut"-information into the symbol of the curve because in the end I would like to have always just one icon for any curve. Additional signs I would just use for materials. On the other hand the icons themselves shouldn't become complicated. I will do my best to provide as clear icons as possible.
Please find my first attempt attached. The colors are not ready but I think this way of illustrating "cut/dont cut" might be more intuitive than an additional abstract scissor icon not connected to the curve it concerns: Using a point for indicating an obstacle and using the core line above a greyed out street for showing a possible shortcut might work. But I would rather find a way to not need an additional color (grey) since I want to stick with a color indicator the severeness of a curve, like you proposed.
I don't like your approach to "cut / don't cut" because it increases the number of similar looking textures from two (regular and long) to potentially six (regular, long, regular don't cut, regular cut, long don't cut, long cut) and their similarity may confuse the driver even more than the current setup (separate texture for cut and don't cut).
My reasoning is that players (should) pay more attention to the road and car than the codriver icons. Players can be helped in this regard by making icons easy to recognize in peripheral vision; that is, even if they don't focus their eyes on them -- and your proposition goes in the opposite direction.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Players can be helped in this regard by making icons easy to recognize in peripheral vision
In my opinion your Scissor icon is very abstract and can only be understood if you see "cut" and "dont cut" at the same time.
My reasoning is that players (should) pay more attention to the road and car than the codriver icons.
My question in that regard is if we really need to display everything the codriver might say. Maybe it's better to stick to the basics and ignore "long" as well as "cut/dont cut" all together.
Last edit: Onsemeliot 2016-01-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In my opinion your Scissor icon is very abstract and can only be understood if you see "cut" and "dont cut" at the same time.
It can be easily understood if the player pays the minimum of attention to the codriver voice saying "cut" or "don't cut". Besides, how much does it take to learn what the icon means? One race? Two races? From then on only the strong contrast of the icons will matter, appearing in peripheral vision. That is, unless you plan to make more icons with the same shape and colors as "cut" and "don't cut".
My question in that regard is if we really need to display everything the codriver might say. Maybe it's better to stick to the basics and ignore "long" as well as "cut/dont cut" all together.
"Long" is already part of the signs as a white plus and I don't see why it would be better to ditch it. And I am against ignoring "cut / don't cut" because they are actually important, especially the latter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It can be easily understood if the player pays the minimum of attention to the codriver voice
In my view the icons should instantly work without any sound. With your argument you don't need any visible signs at all. If our visual clues are not self explanatory at first glance they fail their whole purpose.
"Long" is already part of the signs as a white plus
Well, if what you proposed is the only thing you would accept we shouldn't engage in any discussion about it after all. I didn't know that this is set in stone from your point of view already.
I don't see why it would be better to ditch it.
As mentioned before: The little "+" signs do not stand out. It's easy to miss them. And even as symbols their meaning is totally arbitrary. "+" could indicate a lot of different things:
getting faster at the end
going uphill
can be taken faster
especially difficult
...
I am against ignoring "cut / don't cut" because they are actually important, especially the latter.
But you insist on displaying an independant icon for this information and argue - in strong contrast to the "long" issue - for separation because of clarity. I can understand, that you find your own creations very clear but in such cases usability tests are sometimes cruel. Often it is necessary to let go of loved pet ideas because in practice they do not work. So far I have been the only usability tester and I admit this is hardly a good reference point. To be fair we should let test it other people (ideally without sound) who are totally un-influenced by any knowledge about our word and icon set.
We can leave it like you proposed for 0.6.3, but I expect people to be confused by some icons. It might not keep them from playing but some icons might stay meaningless to them for quite a while - or they do not even get that there are always two versions wit a "+" and without one.
On the other hand I fear by far the biggest off-putting factor for players is still the one we both can't solve: How easily the vehicle gets out of control. Compared to that the whole subject is rather unimportant.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If our visual clues are not self explanatory at first glance they fail their whole purpose.
Most real-life traffic signs are not self-explanatory at first glance. Consider for example the upside-down triangle which means "give way", or the blue slashed circle which means "no parking". Could this mean that real-life traffic signs "fail their whole purpose"?
In the game too there is a learning curve that players are expected to overcome. And how hard can it be to learn, when both the road itself and the voice help?
As mentioned before: The little "+" signs do not stand out. It's easy to miss them.
OK then find a way to incorporate the concept of "long" into the signs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Most real-life traffic signs are not self-explanatory
Only some aren't. But orienting on bad design examples where people actually have to learn those things in order to get a licence won't work in a situation where people are doing things for fun. I don't want to introduce any obstacles we can avoid.
OK then find a way to incorporate the concept of "long" into the signs.
As mentioned earlier I unfortunately can not offer a really satisfying solution. This is the reason why I suggested to ignore it.
Under the given circumstances I guess I can only try to make the "+" more prominent.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This thread contains the table of races which I skipped when adding codriver checkpoints.
It will be continuously updated and the title will change accordingly.
EDIT: apparently, the title cannot be changed.
Last edit: Andrei 2016-01-21
Today I added codriver notes to "Old Quarry". Mainly beacuse it felt rather random if the car went from firm sand to loose sand without any texture indication I added some brightness difference between the road and the surrounding terrain.
I noticed that the terms "opening" and "closing" would be handy and something like "up" and "down" might be of value too for possible future enhancements of the codriver word set.
Yes, many words and expressions could be added to improve the codriver notes. With inspiration from real pacenotes we could add "fast", "hook" and "K" curves, "keep right/left/middle", "tightens/opens into...", "over crest", "over dip" and so on.
Adding new codriver words in the game code is very easy: only the file /src/include/codrivervoice.h needs to be edited, then the rebuilt game will load the corresponding .WAV files at initialization. The hard work is actually recording the voice such that it sounds good.
However for now let's use only what we have, otherwise 0.6.3 will never be finished, or at least not while I'm still active.
Yes of course. As written already, this was not a suggestion for the next release.
Now that you have hidden the codriver circles I experience what I was afraid of all along: If I drift off the road on the wrong position far enough and drive back to it later I do not get any more codriver commands and it's totally unclear for the player why this happens. It feels like a bug.
In my opinion it is definetly safer to disable the cronical order of the codriver commands. It should be enough to pass through the normal checkpoints in the given order.
The only other sensible option I see is making the codriver checkpoints visible too. But this looks rather messy ...
Yes, but this doesn't work for maps containing loops. Are you willing to do these edits yourself? Or shall we start from opposing ends?
Right now I am working on the credits. It seems we will have issues with the co driver notes in every case as soon as someone fails to follow the instructions closely enough since it would be easy to get at least one wrong command when driving in the wrong direction before realising that something went wrong because the driver is hearing no more codriver notes.
The only thing popping into my mind is to add insanely many invisible checkpoints in order to keep track of where the car is going. If the car then leaves the checkpointed area we could give out a warning like: "you left the racing path" and if the checkpoints are passed in the wrong order we could do an other warning: "you are driving in the wrong direction". (See attached image "tracking.png" for reference.)
This way we could use just one array of checkpoints with optional attributes like "visible" and "[a random codriver command]".
But thinking about this I guess it would be much easier to just add an other black and white image where one value indicates the route and the other tells your script to warn the driver since he/she left the racing route. In practice this would mean to just provide an image with a much wider road. (See attached "tracking2.png".)
Would you know how to implement this? Since you managed to do wonders with the terrain map I guess this would be easy for you to do.
Either way: For the future I would prefer to not use two seperate checkpoint sets, but to have only one array of ceckpoints with different atributes for the needed functions.
Last edit: Onsemeliot 2016-01-24
You are right that a black-white roadmap would be much easier than adding many "invisible" checkpoints by hand. However we've already been through the hell of updating maps once: and personally, I'm not willing to spend my days adding B&W roadmap textures.
Anyway, I'll add this suggestion to my To-Do list for 0.6.4.
I think this can be done relatively easily, but I believe this is a bad idea. Nonetheless I shall add it to the To-Do list for 0.6.4 and it will be implemented in a fully backward-compatible fashion so that other map designers can still use separate checkpoint lists.
Certainly not for this release, but I would be willing to add such images later on since I think they could be done rather fast and it would be great to get warned if the car gets to far off the supposed track.
Why?
At the moment we deal with two sets of checkpoints. I think this is much more complicated than necessary since most visible checkpoints could be placed where we would want codriver checkpoints anyway. The process would then be to just make some codriver points visible too.
I have just seen your commit with the codriver symbols. You concat seperate words into phrases and use images for that. This is elegant, but leads to problems where I used the words in an other order. Especially in Marathon there are so many curves following afer another that I used something like "left chicane" istead of "chicane left" because I wanted to give most important information in which direction the next curve will go as fast as possible. I figured this gives the driver a little more headstart in such situations.
I guess I have to redo Marathon now.
And I will try to offer some cooler icons too. Especially challenging are clear icons for different soil materials ...
Gut feeling. The current way of doing things is at least simple and straightforward. The proposed new way could result in unmanageable checkpoint salads. But maybe my intuition misleads me.
That's unfortunate, I hope it won't take you too much time. Theoretically this problem can be "fixed" by simply adding new textures named "LeftChicane.png" and "RightChicane.png". However I am against that because it might break other maps randomly. After all, it's "Marathon" that needs to be fixed, not the other maps.
I am interested to see what you come up with, although I have to admit I'm quite pleased with the current arrow style (but not with the drawings themselves of course).
I argue the opposite since I find it hard to manage right now: We have two totally independent sets of checkpoints which need to be synchronized cerefully in order to work properly. This is a source for potential errors. With my proposal there would be just one set of checkpoints and some of them would just carry a "visible" flag. The only functionality we would loose there is the possibility to have codriver notes for different routes. But you argued that this doesn't a true rally anyway and we just tried it once with "frozen" as far as I can remember.
Unfortunately I don't think this is totally true. But still, for sure it is less work to adapt those cases than all maps. or the basic concept.
Yes, I too think you did a good job there. I only feel the thin lines don't stand out enough. I will try to do something that looks more like the arrow buttons from the menu. So I will try to use thicker strokes for example.
For clarity, I consider the basic formula for codriver notes to be:
(CURVE_TYPE) + (LEFT / RIGHT) [ + LONG [LONG] ] [ + [DONT] CUT ] [ + INTO... ] [ + OVER... ]Let's try to remain disciplined and stick to the above formula, otherwise all our codriver work may start unraveling.
And about the arrow signs, one mistake I have made (which I can't fix) is that their bases are not aligned at the same height. That was not intentional, although the lack of horizontal centering was.
Edit: nevermind the excessive edits to this post, I was having fun with the formula.
Last edit: Andrei 2016-01-25
Unfortunately so far I didn't know there was a formular. Therefore I guess I will need to change a lot in basically all the maps I did the codriver notes for.
This was a failure to communicate on my part, sorry. Even though I coded the codriver notes to work regardless of word order, I had a specific structure in mind which I thought would be self-evident.
That said, I'd like to know in what ways your notes deviate from the above formula.
Since I didn't consider the order fixed I often used things like "left hard chicane" for example. Now I understand this should have been: "chicane left". And a chicane can't be "hard" according to this concept. It would be bad usability to make more symbols since they need to be very clear at first glance to be useful at all.
I just wanted to provide the most important information first. If I don't listen carefully or can't concentrate on listening, I would want to get the most basic information instantly. In my opinion the direction of the next curve is the most important. Only after getting that I probably want more detail like "chicane" oder "hairpin". Of course this doesn't matter if I can have the notes early enough but especially on maps like Marathon there is almost never any time between curves.
And it doesn't help to have more than two or maximum three commands connected via "into" since in practice this is to much information at once - at least for me.
In my opinion it is not...
https://www.youtube.com/watch?v=1sAbQ5wRr0o
https://www.youtube.com/watch?v=rGtCYoBxp6Y
... but I found a video in which the codriver uses your proposed style:
https://www.youtube.com/watch?v=4WcHVkDXdpU
Every rally crew has their own style. Some use words for corner severity, some of them use numbers. Most of them seem to use severity+direction. If we try to build all that into Trigger Rally we'll waste a lot of time adding something of little value. So let's just stick to what we have...
Now that I've added codriver signs the codriver voice isn't as important to listen to, so there's that.
I didn't want to convince you. I just explained my line of thinking because you asked me to. I'm fine with the approach you went for. Unfortunately I didn't understand it in time.
I don't think having many symbols after each other will be much different.
I can't think of a way to incorporate the "long"-attribute in a self-evident way. The "+"-symbol doesn't really work for me.
I would prefer to indicate the "cut"-information into the symbol of the curve because in the end I would like to have always just one icon for any curve. Additional signs I would just use for materials. On the other hand the icons themselves shouldn't become complicated. I will do my best to provide as clear icons as possible.
Please find my first attempt attached. The colors are not ready but I think this way of illustrating "cut/dont cut" might be more intuitive than an additional abstract scissor icon not connected to the curve it concerns: Using a point for indicating an obstacle and using the core line above a greyed out street for showing a possible shortcut might work. But I would rather find a way to not need an additional color (grey) since I want to stick with a color indicator the severeness of a curve, like you proposed.
I don't like your approach to "cut / don't cut" because it increases the number of similar looking textures from two (regular and long) to potentially six (regular, long, regular don't cut, regular cut, long don't cut, long cut) and their similarity may confuse the driver even more than the current setup (separate texture for cut and don't cut).
My reasoning is that players (should) pay more attention to the road and car than the codriver icons. Players can be helped in this regard by making icons easy to recognize in peripheral vision; that is, even if they don't focus their eyes on them -- and your proposition goes in the opposite direction.
In my opinion your Scissor icon is very abstract and can only be understood if you see "cut" and "dont cut" at the same time.
My question in that regard is if we really need to display everything the codriver might say. Maybe it's better to stick to the basics and ignore "long" as well as "cut/dont cut" all together.
Last edit: Onsemeliot 2016-01-25
It can be easily understood if the player pays the minimum of attention to the codriver voice saying "cut" or "don't cut". Besides, how much does it take to learn what the icon means? One race? Two races? From then on only the strong contrast of the icons will matter, appearing in peripheral vision. That is, unless you plan to make more icons with the same shape and colors as "cut" and "don't cut".
"Long" is already part of the signs as a white plus and I don't see why it would be better to ditch it. And I am against ignoring "cut / don't cut" because they are actually important, especially the latter.
In my view the icons should instantly work without any sound. With your argument you don't need any visible signs at all. If our visual clues are not self explanatory at first glance they fail their whole purpose.
Well, if what you proposed is the only thing you would accept we shouldn't engage in any discussion about it after all. I didn't know that this is set in stone from your point of view already.
As mentioned before: The little "+" signs do not stand out. It's easy to miss them. And even as symbols their meaning is totally arbitrary. "+" could indicate a lot of different things:
But you insist on displaying an independant icon for this information and argue - in strong contrast to the "long" issue - for separation because of clarity. I can understand, that you find your own creations very clear but in such cases usability tests are sometimes cruel. Often it is necessary to let go of loved pet ideas because in practice they do not work. So far I have been the only usability tester and I admit this is hardly a good reference point. To be fair we should let test it other people (ideally without sound) who are totally un-influenced by any knowledge about our word and icon set.
We can leave it like you proposed for 0.6.3, but I expect people to be confused by some icons. It might not keep them from playing but some icons might stay meaningless to them for quite a while - or they do not even get that there are always two versions wit a "+" and without one.
On the other hand I fear by far the biggest off-putting factor for players is still the one we both can't solve: How easily the vehicle gets out of control. Compared to that the whole subject is rather unimportant.
Most real-life traffic signs are not self-explanatory at first glance. Consider for example the upside-down triangle which means "give way", or the blue slashed circle which means "no parking". Could this mean that real-life traffic signs "fail their whole purpose"?
In the game too there is a learning curve that players are expected to overcome. And how hard can it be to learn, when both the road itself and the voice help?
OK then find a way to incorporate the concept of "long" into the signs.
Only some aren't. But orienting on bad design examples where people actually have to learn those things in order to get a licence won't work in a situation where people are doing things for fun. I don't want to introduce any obstacles we can avoid.
As mentioned earlier I unfortunately can not offer a really satisfying solution. This is the reason why I suggested to ignore it.
Under the given circumstances I guess I can only try to make the "+" more prominent.