greetings (and a request regarding forum rules)

[arciphera]

greetings, all.

I am a longtime lover/player of DOS games from the late '80s and early '90s - but only a select few compared to most other people on this forum (or so it seems). however, the ones I do love/play - mostly driving/racing simulations (eg: Test Drive, Test Drive 2: The Duel, Test Drive 3: The Passion, Stunts) - I have an almost fanatical attachment to.

the main reason I joined this forum is to seek out someone who might have the know-how to edit/customize specific functions of said games (particularly Test Drive 2). nothing major; just stuff I've always wished was different (for instance, changing the number of lives from however many the game gives you to only one, so that crashing your car at any point in the game is the end of it, just like in real life). before I post such a request, though, I need to make sure that doing so isn't a violation of the forum's rules. I have searched the board index for a topic clarifying this issue but thus far have been unable to find one, if it exists. if it does, a pointer in that direction would be greatly appreciated; otherwise, a confirmation here will suffice.

thanks to everyone in advance.

[Malvineous]

Welcome to the forums!

There aren't many rules here that aren't covered by common sense, so asking about modifying games is certainly fine. Just be aware that *distributing* modified games is often not permitted by various laws (even in the case of shareware where distributing the unmodified game is permitted), so of course you need to be careful about how you do that. (Typically instructions are distributed and then people use those to modify their own copy of the game, thus working around this restriction.)

Having said that, posting a request asking someone else to modify a game for you will likely be met by silence, as most of us here have our own favourite games that we're busy working on. You'll get a much better response if you try to modify the game yourself, and then after you've done plenty of research and you're still stuck, asking specific questions. These are usually quick for experienced people to answer, so you'll be much more likely to get a response, and it also shows that you're willing to put in the effort and you're not just getting someone else to do it for you by proxy.

Generally speaking, the type of changes you're talking about will involve disassembly, where you convert the game's .exe files from machine code back into assembly language, then try to read that to understand what the game is doing. So of course you will need to understand the basics of assembly language in order to do this, but luckily this isn't hard and there are plenty of resources and tutorials on it. So if you completely have no idea where to start, I'd advise learning some simple assembly language and then seeing if you can disassemble a simple program and change it in some manner. Once you understand this you'll be ready to start looking at a larger program like a DOS game.

None of what you want to do is especially difficult, but it can be a very long process reading the code and hunting down the bit you're interested in so it does require quite a bit of patience. This is why other people are not always so interested unless it's a game they are passionate about themselves. But the satisfaction of successfully modifying a game to do something nobody else has done before is very rewarding, so I wholeheartedly recommend giving it a go!

[arciphera]

thank you for the welcoming (and very informative) response, Malvineous.

I am glad to know that requesting help with modding a game is not against the rules here. I do not intend to redistribute the game(s) I want modded, either - this is only for my own personal enjoyment - so that certainly won't be an issue. I was actually going to include an offer to pay for the modding work - a rather handsome amount, if necessary - but your suggestion that I learn how to do it (and do it) myself has convinced me to try that route first. so I shall.

before I even begin the first step toward that objective, however, I would like to ask for your personal input/opinion on the specific mods that I am desiring. the one I mentioned in my first post is actually the simplest one of them all to explain, which is why I chose it as an example. the other mods, however, I am thinking are a bit more intensive - or at least they seem to be in MY mind - so I would appreciate if you could tell me whether they sound to you like things I should realistically expect to be able to eventually learn to do myself...or if they cross the line into serious DOS (re)programming.

I will keep the list of desired mods restricted to only Test Drive 2: The Duel for this post. those mods are:

• I would like to change the number of lives given to the player at the beginning of each new game to 1 (rather than 5) and make it so that the number of lives the player has stays at 1 throughout the entire game (rather than being given an extra life for every new level passed).
• when playing in manual-shift (rather than automatic) mode, if the player runs the car's engine into the red line for longer than four seconds, the engine blows up and the player loses a life. the mod would be to remove that red-line penalty for all 12 cars in the game so that going into the red line for any of them never blows the engine. if this function cannot be completely removed, then setting the penalty timer so that the car's engine blows up a full minute after entering the red line (rather than the paltry 4 seconds the game is set to by default) will be acceptable.
• if the radar detector goes off and the player does not decrease their speed to 50 MPH or slower within a few seconds, the police will come chasing to pull the player over and give them a ticket. I would like to change that speed to 85 MPH (so that the player will not get pulled over by the police unless they are driving 86 MPH or faster).
• each press of the down key (which serves as the brake) equates to a 6-MPH speed reduction. I would like to change this to 3 MPH.
• when playing in manual-shift mode, shifting up is accomplished by pressing the Up key (which serves as the accelerator) in combination with the Space Bar (which serves as the clutch); likewise, shifting down is accomplished by pressing the Down key in combination with the Space Bar. I do not want this functionality removed or changed in any way; instead, I wish to simply add the option of accomplishing a complete shift-up by simply pressing the A key and a complete shift-down by simply pressing the Z key. (the main reason for this is so that shifting down can be accomplished without having to apply the brake.)

so what do you think? based on what you know about DOS programming, would you say I'm aiming unrealistically high with all this stuff? or is it probably a lot easier to (learn how to) do than I've heretofore been assuming?

thanks for your time!

[Malvineous]

I can't answer for sure without having done the reverse engineering and actually looking at the code, but at least at face value, everything except the last change should be fairly easy, and the last one is probably doable as well but would require a bit more effort.

I'm not sure how much programming experience you have, but "DOS programming" isn't really any different to any other sort of programming. There are some limitations (less memory) and the functions you call are different, but the basic principles are all the same. So if you understand the basics of computer programming then the types of mods you want to do will be relatively straightforward. Again the problem is less about changing the code, and more about finding where that particular bit of code is. (The old needle in a haystack problem.)

• Reduce lives from 5 to 1. This is just a matter of finding the code that runs at the start of each game that sets up all the variables, and when it gets to "lives = 5", the 5 just needs to be changed to 1. Being assembly language, it will look more like "mov ax, 5" but the change is the same.
• Extending engine redline time. There could be a few ways they implement this. There might be a count up timer variable, and a check to blow the engine when that variable reaches a certain value. It could be a count down timer, with the engine blowing when the timer reaches 0. You can adjust the value so that it's much larger, extending the time until the engine blows. Or you can patch the check itself so that it is always true (or false) so that you get the behaviour you want regardless of the value of the count.
• Police trigger speed reduction. Again finding the code that says "if speed >= 50" and changing the 50 to 85 should do the trick. Assembly will look more like "cmp ax, 32" (32 being 50 in hex). It could also be 31, if the programmers wrote "if speed > 49", you never know.
• Changing gear shift keys. This one is a bit more ambitious as you may have to insert new code rather than change existing checks. Inserting new code is difficult because you can't shift anything out of the way, you can only write over the top of what's there, without moving anything else. You might get lucky and it's just a matter of putting in a new keycode and blanking out the check for the spacebar, or it might be a more complex condition. There are a number of ways that keypresses are handled, so this can be tricky to hunt down. It's certainly doable, but I'd do this one last

Of course this is assuming a straightforward program. If they have introduced copy protection, anti-hacking/cheating protection and other complications then it will be a much tougher job. Luckily these things are relatively rare however.

It's hard to say whether it's easy or hard as it depends on your experience with computer programming. Usually when you learn programming for the first time at an adult level, they start you out with assembly language because it's so fundamental, so the good thing is if you're learning for the first time, you'll be learning what everyone else starts out with too.

Fair warning though - it's a huge time sink. It's a lot of detective work, reading code and deducing what it does. You need a lot of patience, especially when you're learning, because it will all look like gibberish for a long time until you start to understand what's going on. But once you start to figure it out, it becomes very rewarding and sometimes you even come across potential mods you never thought about before. It's especially interesting when you find easter eggs in the code, and either figure out how to activate them, or patch the game to access them the way you choose to.

As for tools, I'd recommend trying to get hold of a copy of IDA Pro. For a while they released freeware versions which should work fine, as nothing has changed in the DOS world since then. You might also want to investigate the DOSBox debugger, as this allows you to inspect the code while the game is running, and pause it at certain places (e.g. if you can pause it when the level is about to load then you will have a rough idea where to start looking for the code that sets the number of lives to 5.) However the DOSBox debugger doesn't give you a good overview of the code. For that, nothing beats IDA.

Anyway, this will probably give you days of stuff to figure out, so I'll leave it there for now

[arciphera]

wow. that is a lot of info/guidance. thank you.

so I went ahead and got IDA, then I used it to open up the Test Drive 2 executable, and...yikes. the code is about as extensive and appears to be about as unintelligible as I was expecting it to be, but seeing it all laid out at once and not knowing what to do with ANY of it feels daunting, to say the least. I have absolutely no experience with computer programming - none, nada, zip, zilch, zero - so you can imagine what it's like for me at this point. I haven't even looked up, let alone read/studied, any tutorials. I guess that's my next step, though.

I can see now why no one else would want to do this work for me, even if it would be relatively easy for them. I wouldn't want to do it for someone else, either. but I do want it done pretty badly. I've been dreaming about having it done for 30 years. I guess it's time to finally realize that dream. (you can probably tell that I live a pretty simple, non-ambitious existence. ha.) I just hope the code I'm looking at isn't a bunch of encrypted information. it's really going to suck if it is, since the main reason I'm delving into all this mess is to modify this one specific game. then again, maybe I'll see later on what I can do to the other two DOS Test Drive games I love so much. it all depends on how successful I am with modifying this one.

anyway, thanks again for all your help.

[Malvineous]

No worries at all. If you have no experience with programming at all then it would be worth learning how to write some simple assembly language programs first, so that you understand roughly what's going on with the code you're looking at. Like learning to speak another language, you don't have to become an expert, just learn enough keywords that you can get the gist of what's going on.

IDA is good because it can split the code up into separate functions based on where the code jumps around to. It lets you rename these functions so that you can see more easily where they are called. For example if you find a function that makes the engine blow up, then you can rename it to "engineExplode" and then do a search to see what calls the engineExplode function. Chances are it will be just after the game checks how long it's been redlining for, allowing you to narrow down your search for that particular bit of code.

One important skill you'll need to learn early on is how to patch the .exe file based on what you see in IDA. This is because you will want to change some of the instructions (instructions = assembly code) you see in IDA, so you need to know how exactly to do that. The reason this is so important (other than of course you can't actually make the changes you want to if you can't modify the .exe) is that an extremely helpful reverse engineering tactic is to insert some code in a function you are trying to identify that does something obvious, like crashing the game. Then you just play the game until it crashes, and at that point you realise what the function was probably for. Then you can go rename it, and try another function. After a while once things start to get named, you start to get a picture of what all the functions do and you can start narrowing down your search for the specific behaviours you're after.

In fact, this is one of the most useful reverse engineering techniques there is. Most of the time it's entirely unclear what some code does, but by changing it a tiny bit (e.g. some number from a 1 to a 2) and observing any change in the game's behaviour, you can save hours of reading code. You do have to get into the mindset of a detective solving a puzzle though, and this works best with games you are extremely familiar with (so you can spot even the tiniest changes) but in those cases it can dramatically reduce the time spent deciphering code.

Like I say, it's not trivial, and it takes some time to learn, but there's nothing about it that's particularly difficult, it's just a matter of taking the time to learn all the steps. As long as you have the patience and the willingness to learn, then it's a very achievable goal!

[Frenkel]

Nick Shaffner's "Cheat-O-Matic" can be used in the case of changing the number of lives in games.

Or at least it gives you an idea how to find the memory location of the lives-variable and, with the aid of IDA, the code that alters this variable.