Cheat Engine

[LongBeardedLion]

Im planning to make a major hack. Until now i did small things.

i need your opinion to know if this will be too heavy on the memory, or if it is somehow unfeasible.

My game is the good old rts Age of Empires 2.

In the game, there is this unit, Monk, that can convert enemy units. So they become your units. But you must micro them, and click on each unit you want to convert, or else they just sit around.

My objective is to make my monks autoconvert enemy units.

The way im planning to do this. I dont know if it is the most practical way, and would like to know what you think, or if there is a better way.

1- Get my Monk unit position.

2- Go through the enemy units lists, and get each one of their units.
Then make a loop and get into an array the map position of each one of their units.

3- Calculate the square root distance between my Monk and each one of the enemy units (200+ enemy units). Get the ones that are close/within the range of my Monk conversion attack.

4- Call the function to convert one of the enemy units. If there are any closeby.

5- Loop and repeat the above every 2 seconds.

So my question really is. Looping through 200+ units positions, and comparing each one of them with the position of my Monk. Isnt that expensive for the computer? How efficient is that?

Also im planning then to apply this to a group of Monks. Like 10 monks. So that would be checking the locations of 200+ units * 10 monks / every 2 seconds. That would be even more heavy, no?

Should i go for this? Or this is crazy, and it wont work, because too much calculations and resource demanding?

What else suggestions do you have if there are any?
Thank you.

[ParkourPenguin]

Well... let's take some rough estimates. Assuming the memory addresses you're accessing aren't in cache, it'll probably take a few thousand instruction cycles per loop iteration (not including the call to convert a unit, which should be relatively rare). 200 loop iterations in total means roughly 1 million instruction cycles spent on a single check. Given that processors run at a few gigahertz (> 1,000,000,000), it's not unreasonable to think that a single thread could run that check on the order of a thousand times per second - far more than what would be required.
It should be fine to sleep about 100ms between checks. The user won't notice the delay and the cpu will keep up just fine.

This doesn't include other optimizations you could make. Once you find a valid unit, I'm assuming you can exit the loop. It might be a good idea to keep track of which enemy units are closest and check them first next time.


Doing that check for every monk might go poorly if you write the code poorly. CPUs are fast, and it's quite likely a naive solution could still work; however, this would be a good time to start thinking about optimization, particularly for cache usage (this problem is definitely memory bound).
Search for "cache optimization" and you should get a lot of resources.

If you want extreme levels of optimization, this webpage, particularly chapter 2, might be a little advanced for beginners but contains a lot of good information. It makes the same algorithm 42x faster between v0 (a good but simple/naive implementation) and v7 (optimized implementation).
You don't need to go as far as that- just read it and learn why certain changes allow the cpu to do stuff faster. In your case, optimizing the algorithm itself would give better results (triangle inequality can prove some checks are unnecessary between monks), but that could get really complicated fast.

[LongBeardedLion]

Thank you penguin.

What about the plan itself, i terms of functionality, not the performance.
Is there any other alternative that pops into your mind?

Do gamedevs do it this way? Do they scan constantly for nearby units on each unit? Or there is a better approach?

I dont know why but it seems my idea is so primitive. But perhaps its truly the only way, and there is no real magic about it?

[ParkourPenguin]

Computers operate under a set of well defined, concrete rules- the contrary to abstract concepts so easily construed by people as simplifications from trifles unnecessary for everyday life.
It's easy to look at the screen and understand if two units are nearby each other, but the computer needs to know what nearby means. I think the solution you've given is good enough.

There are "better" ways of doing this. Collision detection is the more general form of this problem; however, I'd argue such algorithms and optimizations are an unneeded complexity if the simpler solution you've found is sufficient.

Maybe you could get incredibly lucky and find some structure the game maintains referencing nearby units.

[atom0s]

[LongBeardedLion]

Thank you atomos.

Both your answers were great. I gave reputation to Penguin, now i cant give anymore .

There should be a way around this