At the moment it is odd that no matter how hard you crash – the car will always be totally fine. I don't talk of showing the physical damage. (The game propably lacks the necessary detail for that. It might be possible to work with a second texture for damage that could be blended over the normal one according to the amount of damage.) But how about an on-screen account of damage after crashing the car and some effect on how the cars drive. This would introduce an effective penalty for not being cautious. What do you think?
But it might be complicated to decide how to calculate the damage. Is there a way to somehow keep a running total of the (unusual) forces the car was subjected to? Like rolling over and smashing against a tree.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Accumulating the forces of each crash is a relatively easy to implement. I think just adding one "crash" texture could be a start. So when the car accumulated enough crash force, it would be displayed on the car model. The next step could be to add more crash textures, e.g. 25%, 50%, 75%, 100% crash textures.
If you draw such a texture for one of the cars, I could write the code to calculate the damage and display the texture. I think it would be good to have extra attributes in the vehicle files to define the the path to the texture and the amount of energy in Newton after which the texture should be displayed. Ideally this can be already done in the form of a list to add the 25%, 50%, etc. textures later.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wonder if we could use a greyscale texture that would be added to the normal car texture according to the percentage of damage. This way darker areas would get darker and bright areas would leave the original texture untouched.
This way we could avoid the need for including different damage textures for different paint jobs. On the other hand it could be nice too to have bright scratches in the paint job instead. This wouldn't be possible using the method I described.
I'm uncertain what would look best. I can imagine having a greyscale image for dents and a white layer for scratches would be a nice combination. But it might be to much to combine car textures in that way.
But actually the physical damage influencing the cars behaviour is more exiting to me. I would be fine with just an on-screen indicator for damage. We could use a car icon from above where you could see the amount of damage on sides, front, back and roof by colouring the areas in different colours like red, orange, yellow and grey (or white) for undamaged areas.
I think a greyscale texture, that is displayed with more intensity the more damage the car receives, is a good idea. Also scratch textures could be added at the point of impact.
I think the damage model that you outlined is a feasible implementation. Anyway the car is essentially a box and the with 6 sides. The main question is how damage should affect the drive-ability of the car. For example damage on the left could constantly pull the vehicle to the left. One mechanism could be to add some drag, friction or resistance to the two wheels of the damaged side, e.g. damage on the rear means higher friction of both rear wheels.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your ideas for the physical effects of damage sound great to me. But we need to be careful about the amount of the damage effects. Otherwise we probably need to set different target times on many maps. (But they are actually only meaningful in events because in single race maps you can practically ignore time limits.)
Maybe the colour change on the OSD car model isn't the best idea because it might be to distracting. I will try to find other ways to indicate damage in a still clear but less distracting way. I wonder if we even want to include the roof as something that can have damage because it probably shouldn't influence the physics of driving anyway. (Theoretically it could because of the disturbed air flow at higher speeds but I suspect this shouldn't be a real factor in a rally car.)
If I understand you properly then you would just want a scratch texture that isn't located anywhere specific on any car mesh. But I suspect the greyscale texture would be a whole body texture which can't be shown more or less on any specific area. Or do you propose to somehow define parts of the car mesh to be covered independently with damage textures?
One fun thing I can think of would be a broken glass texture.
Last edit: Onsemeliot 2020-11-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think it is OK, that heavy damage make it more difficult to reach the target times, as the damage is a punishment for a bad driving style. Of course balancing the impact is important to not frustrate the players. I agree, roof damage should be at least a less important feature than chassis damage. I think this would only influence the air drag.
There are many possibilities of how to apply crash textures. I am not sure whether to start with a simple implementation and later improve it, if the feature proves itself. This would mean start with a whole body crash texture and later move to multiple independent damage textures. If you look at the texture image files, you can see, that the surfaces of the different parts of the car are already split (front, rear, left, right, bottom, wheels). I will check whether I can get "hold" of e.g. the front part of the texture inside the code. If that is possible, having different damage areas following the split from the texture file would be a simple thing. I think it makes sense, that the graphics designer would follow the same texture layout for the greyscale damage texture as the main texture of the car. Maybe that damage texture can already be bound to the model in Blender, so the engine code could be used to load it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wanted to create my own cars for Trigger rally but so far I haven't figured out what export options I need to use to actually be able to use it in Trigger Rally. Therefore, I couldn't do anything in that regard. I just created textures using the already existing texture files as a reference. Some of them are very unluckily distorted in the texture files (different parts in different ways). This is the reason I often wasn't able to use more advanced paint jobs.
I just realised that creating black and white damage textures might be difficult because I hid the strange shadows some car models had by making the textures unusually dark in the first place. (Most real rally cars are white with loads of stuff on it but mostly white. This didn't look very good when I tried. Therefore, creating dark shadows to indicate damage might not make much difference. I guess bright scratches might do more to create something like a rugged look.
Last edit: Onsemeliot 2020-12-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the ability to export models and the associated textures is quite important to add crash textures to the model. I will have a look into that.
In the meantime I implemented another part of the damage feature. The game shows the damage indicators you proposed above in the right part of the screen. If you crash trees and other world objects or flip the car over, the indicators will go from green to yellow to red. You can use the patch in the attached ZIP-file for testing. You also have to put the three PNG files into "data/textures". The implementation does not yet have an impact on drive-ability.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As usual, your implementation works very well at the first attempt.
I only wished the damage indicator wasn't that large. I would include it about the height of the two checkpoint lines (on the top right corner and right next to it). I also would prefer not having rounded corners but instead a little more gap between the different parts.
I still wonder if something with less colours would work but it's very nice that you implemented a seemingly step less shift from green to red and this probably wouldn't be possible with any other way of displaying the same information.
Maybe you could add black after red for indicating even greater damage. And I tried very hard to damage the roof but it always stayed green. Is it possible that the code doesn't work for the roof yet?
An other thought I had: Since the most relevant damage we could have in terms of drive-ability is probably the wheels we might want to focus the damage on the wheels instead of the car body. But on the other hand it would be strange if it didn't show on the body. But if we want to focus on the wheels our areas are probably not so well chosen. We should have the four corners instead of the sides as relevant damage areas. But since you already worked on the first proposal I would understand if you didn't want to change it afterwards.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I only wished the damage indicator wasn't that large. I would include it about the height of the two checkpoint lines (on the top right corner and right next to it). I also would prefer not having rounded corners but instead a little more gap between the different parts.
All points can be changed quite easily. You can actually remove the rounded corners yourself by making the three PNG files all white.
I still wonder if something with less colours would work but it's very nice that you implemented a seemingly step less shift from green to red and this probably wouldn't be possible with any other way of displaying the same information.
Maybe you could add black after red for indicating even greater damage.
Adding the transition from red to black is possible. However, I think it less logical than the pure traffic light color scheme. A less colorful alternative could be a transition from white to black. I checked a few other racing games and most of them use the traffic light scheme. So I would stick with that coloring right now.
And I tried very hard to damage the roof but it always stayed green. Is it possible that the code doesn't work for the roof yet?
The roof damage is a weak point of the current implementation. When it comes to collision detection the car is essential a box. The cars are longer than the are wide and they are wider than they are high, e.g. the Cordo car is 2.5 long, 2.0 wide and 1.0 high. The collision with the ground is detected, when the Z-position of one of the upper four corners of the box is lower than the ground. To determine which of the 5 damage indicators should receive the damage, the code calculates the which center position of the 5 surfaces of the box (lower surface is not considered) is closest to the positions at which the edges touch or cross the terrain. As the front and back surfaces of the car are the smallest, the center of these surfaces has the shortest distance to one of the four edges touching the terrain. The problem of the upper surface is, that is the largest, because the car is longer and wider than it is high. I have to figure out a better implementation on how to distribute the damage. Alternatively the roof damage indicator could be removed. I think that is maybe the best for the start.
An other thought I had: Since the most relevant damage we could have in terms of drive-ability is probably the wheels we might want to focus the damage on the wheels instead of the car body. But on the other hand it would be strange if it didn't show on the body. But if we want to focus on the wheels our areas are probably not so well chosen. We should have the four corners instead of the sides as relevant damage areas. But since you already worked on the first proposal I would understand if you didn't want to change it afterwards.
Having the corners instead of the sides as damage areas would definitely solve the issue with the roof that I described above. At least for collisions with the terrain, the code anyway uses the upper four corners of the box for collision detection. Making the change is not a problem, the code would actually even be more simple in that case. However, I am not sure yet, whether such a damage model would be intuitive. for the player I have to give that another thought.
I made some progress regarding the vehicle models. I was able to import a model with Blender, export it to another directory and use it in the game. The only thing I had to do additionally is to remove an unwanted "newmtl" entry in the MTL file and change that path to the texture from absolute to relative. There were no changes required to the OBJ file. Maybe that helps you to create a crash texture to the vehicle model that is already included in the model data.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
However, I am not sure yet, whether such a damage model would be intuitive.
I attached a proposal for a new small damage image.
The only thing I had to do additionally is to remove an unwanted "newmtl" entry in the MTL file and change that path to the texture from absolute to relative.
Thank you. I will look into it again. Maybe that was all that messed it up for me. But I fear it was something else because didn't have the problem of a model without texture. There was just no model recognised at all.
I like the new damage indicators a lot. I will implement them when I have the time.
When I exported the model and tried to use it without modifying the MTL file, the model was not displayed at all. So it looks like we are facing the same issue. Only when I removed the second "newmtl" entry, the car was displayed without a texture. After changing the path to the texture file, everything looked fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had more time than I expected, so I implemented the new indicators right away. :-)
The code changes and the four new damage indicator image files are in the attached ZIP file.
The new design feels quite intuitive in the game, so I am quite happy with it. Please share your feedback. If the general design is OK for you, I would start implementing the impact of the damage on the car behavior.
It works flawlessly again. I only fear it could be wrongly seen as a zero. And then it would be unclear what it means. Also the four parts do create a fine line (cross) between them. (See the screenshot I attached.) I still would place the whole thing top right.
And since the lettering sometimes has cut off parts of other letters (for example the "4" in the top center) I wonder if it wouldn't be more sensible to use an actual font to render the text instead of parts of a big font-tile showing different parts as needed.
And would it be considerably more difficult to use svg files instead of pixel images for the on screen display?
I can add the text "Damage" above the four indicators to make the purpose more clear. I placed the damage indicator close to the tachometer to have all vehicle related information in one place. Putting it in the top right corner next to the checkpoint information would put in another context (track progress). Another solution would be to place it left of the tachometer.
I also noticed the fine cross between the indicators. I assume this is a side effect of the image scaling and rasterization. I will try to find a solution for the issue.
I also wondered why the creators of the game chose this solution for displaying letters. I can check how difficult it would be to use a regular font. Regarding the SVG format, I have actually never seen a game that stores images in vector graphics. I am really not sure why. I assume this is because of performance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Allright. I just looked at the positioning from a design angle. Maybe it would be better included into the OSD element for the car. (See the again adapted attached screenshot.)
I have actually never seen a game that stores images in vector graphics. I am really not sure why. I assume this is because of performance.
That is interesting since I am used to vector graphics being considerably lighter. But maybe less in terms of performance than the needed storage space.
I like your new proposal and implemented it right away. The changes are located in the attached ZIP file. I modified the rev dial background for that purpose. I also changed the four damage indicator images to fix the cross issue. I just added the pixels directly at the border of the image to the transparent background. I think the cross was a side-effect of the linear filtering of the texture and the fact that textures are drawn repetitively in Open GL by default, so that the next copy of the texture overlapped into the rendered image.
I also added a new feature, which leads to flashing of the damage indicator, when it receives damage. So it is more visible to the player, if he or she damages the car, especially now that the indicators are quite small.
I assume the size of the graphics on the disk is not so important for video games. In the end the image has to be rasterized anyway to be drawn on the screen which will need additional RAM (to store both the original and the SVG) and computing power.
It works still perfectly fine. And in my view the positioning is much cleaner that way.
Would it be difficult to keep the damage on specific cars during an event? This could allow the situation that you can't just destroy the car on one map and carry on using it in the next race as if nothing has happened. What do you think? You would need to drive carefully or switch to an other car if you want to achieve good times for the whole event.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I understand what your are referring to. Some commercial rally games have the possibility to repair the car between the stages of the same event. So you have to take care to not damage the car too much, because you could end without a working car. A more simple implementation could be, like you are suggesting, that you have three cars available for an event and the player could change to the next car between races.
I will first implement, that the damage affects the driveability. I will look at feature like taking the damage from race to race once that part is working and included in the repository.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes you got me right. And of course having a physical effect of the damage in the first place is much more valuable. I am just always on the lookout for making the experience more interesting than before. And I believe the introduction of unlocking events and cars through winning previous events improved the game very much. Before we had that it didn't matter if you have played the game before because it was always the same when you started it. Having some kind of obstacle to overcome does increase my motivation and it gives some kind of accomplishment if I am able to build on something I have done before on which I can improve on to actually get more out of the whole experience.
If you have ideas that would bring the game more in that direction I would be very interested in that. I for example very much liked the historic career mode in Need For Speed Porsche where you could win historic cars depending on the time frame the setting was in and make progress this way. Therefore, you could always drive older cars in the future but you did have more powerful and easier to handle options becoming available as the game years passed by.
I also liked the possibility to customise the paint jobs of cars by choosing base colours and additional elements like numbers. This way the cars felt much more personalised. But I suspect this would only be sensible if we did replace the car meshes for models with a little more polygons that don't cast odd shadows on bright paint jobs. But If I got you right adapting the base colour shouldn't be hard to do because having transparent textures that overlap isn't a difficult feature.
But maybe the next best step – as you already mentioned – would be to actually make the growing list of possible customisation accessible through an intuitive in-game menu page for settings.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I added a patch with a first implementation in which damage impacts the behavior of the car. The effect is, that the amount of force the wheel transfers both for propulsion and steering is limited. The effect is stronger, if the damage is higher. Please let me know your feedback.
If you have a suggestion for the structure of additional items in the in-game menu, please share it (maybe in another thread). I will review it and share my feedback.
Thanks. I finally added you to the developers list. Therefore, from now on you should be able to add your changes directly to the code.
The physical damage model seems to work pretty well. I only would try to make it more intuitive by adding some drag to the side that is damaged. This would create the effect that you constantly have to correct for driving straight if one side is more damaged than the other. Maybe it would be sensible to reduce the damage impact on steering in general when doing that. What do you think?
I will do a draft for an in-game options menu that allows players to alter the options that can be altered in the configuration file at the moment. (I hope I did understand your intentions correctly and this is actually what you wanted to suggest.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have just installed Blender again and I hopefully we will be able to alter textures and maybe even the meshes in a useful way.
At the moment I have the problem that some meshes are very strangely built and therefore it is very hard to create textures that aren't very distorted. Maybe I can fix that soon.
Martin, do you think we could even somehow alter the coordinates of vertices in order to really reshape the car meshes according to the amount of damage? In theory this shouldn't be to hard on system performance because it would still be the same amount of vertices. Just in slightly different positions.
I can imagine having two instead of just one mesh for every car. We do have the undamaged state already. If we would include a second mesh representing the maximum deformed vehicle the engine then could compare the coordinates and close in on the damage mesh according to the amount of damage it has. If we could import Gimp selections we would even have handy areas and could ignore all non-affected vertices when the re-calculation of the mesh is done.
I don't know if such a re-set would be easy, hard or even impossible with the game engine we have. (Maybe you can answer that.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At the moment it is odd that no matter how hard you crash – the car will always be totally fine. I don't talk of showing the physical damage. (The game propably lacks the necessary detail for that. It might be possible to work with a second texture for damage that could be blended over the normal one according to the amount of damage.) But how about an on-screen account of damage after crashing the car and some effect on how the cars drive. This would introduce an effective penalty for not being cautious. What do you think?
But it might be complicated to decide how to calculate the damage. Is there a way to somehow keep a running total of the (unusual) forces the car was subjected to? Like rolling over and smashing against a tree.
Hello again :-)
Accumulating the forces of each crash is a relatively easy to implement. I think just adding one "crash" texture could be a start. So when the car accumulated enough crash force, it would be displayed on the car model. The next step could be to add more crash textures, e.g. 25%, 50%, 75%, 100% crash textures.
If you draw such a texture for one of the cars, I could write the code to calculate the damage and display the texture. I think it would be good to have extra attributes in the vehicle files to define the the path to the texture and the amount of energy in Newton after which the texture should be displayed. Ideally this can be already done in the form of a list to add the 25%, 50%, etc. textures later.
Hi Martin,
I wonder if we could use a greyscale texture that would be added to the normal car texture according to the percentage of damage. This way darker areas would get darker and bright areas would leave the original texture untouched.
This way we could avoid the need for including different damage textures for different paint jobs. On the other hand it could be nice too to have bright scratches in the paint job instead. This wouldn't be possible using the method I described.
I'm uncertain what would look best. I can imagine having a greyscale image for dents and a white layer for scratches would be a nice combination. But it might be to much to combine car textures in that way.
But actually the physical damage influencing the cars behaviour is more exiting to me. I would be fine with just an on-screen indicator for damage. We could use a car icon from above where you could see the amount of damage on sides, front, back and roof by colouring the areas in different colours like red, orange, yellow and grey (or white) for undamaged areas.
I think a greyscale texture, that is displayed with more intensity the more damage the car receives, is a good idea. Also scratch textures could be added at the point of impact.
I think the damage model that you outlined is a feasible implementation. Anyway the car is essentially a box and the with 6 sides. The main question is how damage should affect the drive-ability of the car. For example damage on the left could constantly pull the vehicle to the left. One mechanism could be to add some drag, friction or resistance to the two wheels of the damaged side, e.g. damage on the rear means higher friction of both rear wheels.
Your ideas for the physical effects of damage sound great to me. But we need to be careful about the amount of the damage effects. Otherwise we probably need to set different target times on many maps. (But they are actually only meaningful in events because in single race maps you can practically ignore time limits.)
Maybe the colour change on the OSD car model isn't the best idea because it might be to distracting. I will try to find other ways to indicate damage in a still clear but less distracting way. I wonder if we even want to include the roof as something that can have damage because it probably shouldn't influence the physics of driving anyway. (Theoretically it could because of the disturbed air flow at higher speeds but I suspect this shouldn't be a real factor in a rally car.)
If I understand you properly then you would just want a scratch texture that isn't located anywhere specific on any car mesh. But I suspect the greyscale texture would be a whole body texture which can't be shown more or less on any specific area. Or do you propose to somehow define parts of the car mesh to be covered independently with damage textures?
One fun thing I can think of would be a broken glass texture.
Last edit: Onsemeliot 2020-11-24
I think it is OK, that heavy damage make it more difficult to reach the target times, as the damage is a punishment for a bad driving style. Of course balancing the impact is important to not frustrate the players. I agree, roof damage should be at least a less important feature than chassis damage. I think this would only influence the air drag.
There are many possibilities of how to apply crash textures. I am not sure whether to start with a simple implementation and later improve it, if the feature proves itself. This would mean start with a whole body crash texture and later move to multiple independent damage textures. If you look at the texture image files, you can see, that the surfaces of the different parts of the car are already split (front, rear, left, right, bottom, wheels). I will check whether I can get "hold" of e.g. the front part of the texture inside the code. If that is possible, having different damage areas following the split from the texture file would be a simple thing. I think it makes sense, that the graphics designer would follow the same texture layout for the greyscale damage texture as the main texture of the car. Maybe that damage texture can already be bound to the model in Blender, so the engine code could be used to load it.
I wanted to create my own cars for Trigger rally but so far I haven't figured out what export options I need to use to actually be able to use it in Trigger Rally. Therefore, I couldn't do anything in that regard. I just created textures using the already existing texture files as a reference. Some of them are very unluckily distorted in the texture files (different parts in different ways). This is the reason I often wasn't able to use more advanced paint jobs.
I just realised that creating black and white damage textures might be difficult because I hid the strange shadows some car models had by making the textures unusually dark in the first place. (Most real rally cars are white with loads of stuff on it but mostly white. This didn't look very good when I tried. Therefore, creating dark shadows to indicate damage might not make much difference. I guess bright scratches might do more to create something like a rugged look.
Last edit: Onsemeliot 2020-12-12
I think the ability to export models and the associated textures is quite important to add crash textures to the model. I will have a look into that.
In the meantime I implemented another part of the damage feature. The game shows the damage indicators you proposed above in the right part of the screen. If you crash trees and other world objects or flip the car over, the indicators will go from green to yellow to red. You can use the patch in the attached ZIP-file for testing. You also have to put the three PNG files into "data/textures". The implementation does not yet have an impact on drive-ability.
For some reason I cannot attach files here, so I created a ticket and attached it there.
As usual, your implementation works very well at the first attempt.
I only wished the damage indicator wasn't that large. I would include it about the height of the two checkpoint lines (on the top right corner and right next to it). I also would prefer not having rounded corners but instead a little more gap between the different parts.
I still wonder if something with less colours would work but it's very nice that you implemented a seemingly step less shift from green to red and this probably wouldn't be possible with any other way of displaying the same information.
Maybe you could add black after red for indicating even greater damage. And I tried very hard to damage the roof but it always stayed green. Is it possible that the code doesn't work for the roof yet?
An other thought I had: Since the most relevant damage we could have in terms of drive-ability is probably the wheels we might want to focus the damage on the wheels instead of the car body. But on the other hand it would be strange if it didn't show on the body. But if we want to focus on the wheels our areas are probably not so well chosen. We should have the four corners instead of the sides as relevant damage areas. But since you already worked on the first proposal I would understand if you didn't want to change it afterwards.
I only wished the damage indicator wasn't that large. I would include it about the height of the two checkpoint lines (on the top right corner and right next to it). I also would prefer not having rounded corners but instead a little more gap between the different parts.
All points can be changed quite easily. You can actually remove the rounded corners yourself by making the three PNG files all white.
I still wonder if something with less colours would work but it's very nice that you implemented a seemingly step less shift from green to red and this probably wouldn't be possible with any other way of displaying the same information.
Maybe you could add black after red for indicating even greater damage.
Adding the transition from red to black is possible. However, I think it less logical than the pure traffic light color scheme. A less colorful alternative could be a transition from white to black. I checked a few other racing games and most of them use the traffic light scheme. So I would stick with that coloring right now.
And I tried very hard to damage the roof but it always stayed green. Is it possible that the code doesn't work for the roof yet?
The roof damage is a weak point of the current implementation. When it comes to collision detection the car is essential a box. The cars are longer than the are wide and they are wider than they are high, e.g. the Cordo car is 2.5 long, 2.0 wide and 1.0 high. The collision with the ground is detected, when the Z-position of one of the upper four corners of the box is lower than the ground. To determine which of the 5 damage indicators should receive the damage, the code calculates the which center position of the 5 surfaces of the box (lower surface is not considered) is closest to the positions at which the edges touch or cross the terrain. As the front and back surfaces of the car are the smallest, the center of these surfaces has the shortest distance to one of the four edges touching the terrain. The problem of the upper surface is, that is the largest, because the car is longer and wider than it is high. I have to figure out a better implementation on how to distribute the damage. Alternatively the roof damage indicator could be removed. I think that is maybe the best for the start.
An other thought I had: Since the most relevant damage we could have in terms of drive-ability is probably the wheels we might want to focus the damage on the wheels instead of the car body. But on the other hand it would be strange if it didn't show on the body. But if we want to focus on the wheels our areas are probably not so well chosen. We should have the four corners instead of the sides as relevant damage areas. But since you already worked on the first proposal I would understand if you didn't want to change it afterwards.
Having the corners instead of the sides as damage areas would definitely solve the issue with the roof that I described above. At least for collisions with the terrain, the code anyway uses the upper four corners of the box for collision detection. Making the change is not a problem, the code would actually even be more simple in that case. However, I am not sure yet, whether such a damage model would be intuitive. for the player I have to give that another thought.
I made some progress regarding the vehicle models. I was able to import a model with Blender, export it to another directory and use it in the game. The only thing I had to do additionally is to remove an unwanted "newmtl" entry in the MTL file and change that path to the texture from absolute to relative. There were no changes required to the OBJ file. Maybe that helps you to create a crash texture to the vehicle model that is already included in the model data.
I attached a proposal for a new small damage image.
Thank you. I will look into it again. Maybe that was all that messed it up for me. But I fear it was something else because didn't have the problem of a model without texture. There was just no model recognised at all.
Last edit: Onsemeliot 2020-12-23
I like the new damage indicators a lot. I will implement them when I have the time.
When I exported the model and tried to use it without modifying the MTL file, the model was not displayed at all. So it looks like we are facing the same issue. Only when I removed the second "newmtl" entry, the car was displayed without a texture. After changing the path to the texture file, everything looked fine.
I had more time than I expected, so I implemented the new indicators right away. :-)
The code changes and the four new damage indicator image files are in the attached ZIP file.
The new design feels quite intuitive in the game, so I am quite happy with it. Please share your feedback. If the general design is OK for you, I would start implementing the impact of the damage on the car behavior.
It works flawlessly again. I only fear it could be wrongly seen as a zero. And then it would be unclear what it means. Also the four parts do create a fine line (cross) between them. (See the screenshot I attached.) I still would place the whole thing top right.
And since the lettering sometimes has cut off parts of other letters (for example the "4" in the top center) I wonder if it wouldn't be more sensible to use an actual font to render the text instead of parts of a big font-tile showing different parts as needed.
And would it be considerably more difficult to use svg files instead of pixel images for the on screen display?
I can add the text "Damage" above the four indicators to make the purpose more clear. I placed the damage indicator close to the tachometer to have all vehicle related information in one place. Putting it in the top right corner next to the checkpoint information would put in another context (track progress). Another solution would be to place it left of the tachometer.
I also noticed the fine cross between the indicators. I assume this is a side effect of the image scaling and rasterization. I will try to find a solution for the issue.
I also wondered why the creators of the game chose this solution for displaying letters. I can check how difficult it would be to use a regular font. Regarding the SVG format, I have actually never seen a game that stores images in vector graphics. I am really not sure why. I assume this is because of performance.
Allright. I just looked at the positioning from a design angle. Maybe it would be better included into the OSD element for the car. (See the again adapted attached screenshot.)
That is interesting since I am used to vector graphics being considerably lighter. But maybe less in terms of performance than the needed storage space.
I like your new proposal and implemented it right away. The changes are located in the attached ZIP file. I modified the rev dial background for that purpose. I also changed the four damage indicator images to fix the cross issue. I just added the pixels directly at the border of the image to the transparent background. I think the cross was a side-effect of the linear filtering of the texture and the fact that textures are drawn repetitively in Open GL by default, so that the next copy of the texture overlapped into the rendered image.
I also added a new feature, which leads to flashing of the damage indicator, when it receives damage. So it is more visible to the player, if he or she damages the car, especially now that the indicators are quite small.
I assume the size of the graphics on the disk is not so important for video games. In the end the image has to be rasterized anyway to be drawn on the screen which will need additional RAM (to store both the original and the SVG) and computing power.
It works still perfectly fine. And in my view the positioning is much cleaner that way.
Would it be difficult to keep the damage on specific cars during an event? This could allow the situation that you can't just destroy the car on one map and carry on using it in the next race as if nothing has happened. What do you think? You would need to drive carefully or switch to an other car if you want to achieve good times for the whole event.
I think I understand what your are referring to. Some commercial rally games have the possibility to repair the car between the stages of the same event. So you have to take care to not damage the car too much, because you could end without a working car. A more simple implementation could be, like you are suggesting, that you have three cars available for an event and the player could change to the next car between races.
I will first implement, that the damage affects the driveability. I will look at feature like taking the damage from race to race once that part is working and included in the repository.
Yes you got me right. And of course having a physical effect of the damage in the first place is much more valuable. I am just always on the lookout for making the experience more interesting than before. And I believe the introduction of unlocking events and cars through winning previous events improved the game very much. Before we had that it didn't matter if you have played the game before because it was always the same when you started it. Having some kind of obstacle to overcome does increase my motivation and it gives some kind of accomplishment if I am able to build on something I have done before on which I can improve on to actually get more out of the whole experience.
If you have ideas that would bring the game more in that direction I would be very interested in that. I for example very much liked the historic career mode in Need For Speed Porsche where you could win historic cars depending on the time frame the setting was in and make progress this way. Therefore, you could always drive older cars in the future but you did have more powerful and easier to handle options becoming available as the game years passed by.
I also liked the possibility to customise the paint jobs of cars by choosing base colours and additional elements like numbers. This way the cars felt much more personalised. But I suspect this would only be sensible if we did replace the car meshes for models with a little more polygons that don't cast odd shadows on bright paint jobs. But If I got you right adapting the base colour shouldn't be hard to do because having transparent textures that overlap isn't a difficult feature.
But maybe the next best step – as you already mentioned – would be to actually make the growing list of possible customisation accessible through an intuitive in-game menu page for settings.
I added a patch with a first implementation in which damage impacts the behavior of the car. The effect is, that the amount of force the wheel transfers both for propulsion and steering is limited. The effect is stronger, if the damage is higher. Please let me know your feedback.
If you have a suggestion for the structure of additional items in the in-game menu, please share it (maybe in another thread). I will review it and share my feedback.
Thanks. I finally added you to the developers list. Therefore, from now on you should be able to add your changes directly to the code.
The physical damage model seems to work pretty well. I only would try to make it more intuitive by adding some drag to the side that is damaged. This would create the effect that you constantly have to correct for driving straight if one side is more damaged than the other. Maybe it would be sensible to reduce the damage impact on steering in general when doing that. What do you think?
I will do a draft for an in-game options menu that allows players to alter the options that can be altered in the configuration file at the moment. (I hope I did understand your intentions correctly and this is actually what you wanted to suggest.)
Yes, that's exactly what I wanted to suggest. :-)
I will check how to make the car pull in one direction, if one side of the car is damaged.
I have just installed Blender again and I hopefully we will be able to alter textures and maybe even the meshes in a useful way.
At the moment I have the problem that some meshes are very strangely built and therefore it is very hard to create textures that aren't very distorted. Maybe I can fix that soon.
Martin, do you think we could even somehow alter the coordinates of vertices in order to really reshape the car meshes according to the amount of damage? In theory this shouldn't be to hard on system performance because it would still be the same amount of vertices. Just in slightly different positions.
I can imagine having two instead of just one mesh for every car. We do have the undamaged state already. If we would include a second mesh representing the maximum deformed vehicle the engine then could compare the coordinates and close in on the damage mesh according to the amount of damage it has. If we could import Gimp selections we would even have handy areas and could ignore all non-affected vertices when the re-calculation of the mesh is done.
I don't know if such a re-set would be easy, hard or even impossible with the game engine we have. (Maybe you can answer that.)