After battle reports

Hey everyone…

I think its time to update this ‘after battle reports’. That means that it would be awesome to c how someone attacked you, so you can see to make your base even stronger :slight_smile:

Attack History is the first thing you see when you fire it up.

 

eh?

No, I mean you can watch a attack of someone else. So you see this movie from your enemies ‘view’. So you see a king with soldiers walking on your path. Not like just the data at the end but also how he exactly did it

(Sorry for bad english)

Your English is good!

 

Agree that would be neat.

 

This has been suggested by others and if I remember correct, this cannot be done.

this was part of many games - iirc you could do this in starcraft and warcraft3. simply the clicks (when&where) were recorded and stored to a file. also in some quake versions and counterstrike ( or halflife in general?) you could record games.

so of course it is possible. it is just not implemented.

however i agree: wanna have it :wink:

Storing the clicks alone and then reinserting as fake input to a new raid with same stats is not enough… you also need to store all info about the attacker’s hero stats and gear, his spell and troop levels, as well as the complete base layout at the time of the attack, including troop levels, wave composition, path layout, tower/obstacle placement and levels.

This is necessary because a single raid’s “starting point” is the conditions that are there, and those constantly change, unlike some games where you always start with the same starting goods / weapons for a certain match or mission.

 

And don’t forget that unlike to those games where several players play together / against each other simultaneously, in royal revolt 2 only the attacker is online at the time of attack, while the defender MUST be offline, so an instant replay after the battle is not an option here. Instead, all that data has to be saved and stored somewhere until the defender logs in again (possible hours or even days later), which makes it all even harder - especially if you consider you might get 20 or more attacks over night. I remember a night with open base for testing reasons, where it showed over 50 attacks when I came back online the next day… that’s a lot of data to store and manage! :grinning:

 

Also, such “record input, restart raid and reinsert the recorded input” methods do NOT guarantee in any way that the result of the replay is the same as in the original raid. There are several factors limiting accuracy, among them exact timing of the re-inserted input (e.g. little laggs / different FPS count and fluctuations on play and re-play, how to simulate an input in-between of two frames, etc?), accuracy of recording (i.e. do all input events get recorded each frame (which can drastically differ in length), or in fixed time-steps or …?), possible rounding errors while recording and storing data, some “random noise” from whatever (re)actions of game entities (walking, target-seeking, etc) involve some chance-based mechanics, bugs such as the units-stuck-inside-barricade/blockade issue that may or may not appear (or may just appear at different time or frequency), and don’t forget the constant recording and synching of data itself also depends on speed of device processor, memory access and network connection/speed, meaning increased network data traffic as well as tiny (but potentially summing up) errors from small hiccups anywhere outside of the actual game… and possible even more stuff that I don’t remember right now. And, of course, you also have to deal with different input methods (keyboard, mouse, touchscreen) and things like continuously-moving long tap/swipe to maneuver a king to some specific location or direction (and not just a discrete single click) and get all that stuff into a common and consistent representation for the recording and replay.

 

Such issues also appear for replays in some first-person-shooter games and can lead to e.g. bullets missing the killed player on the replay, just to name one example.

 

But to give some rough idea of how drastically results could differ in RR2, just take a look at this “simple” scenario that spans over a short time interval of 10 seconds:

A king starts the raid, summons a few troops very quickly (i.e. almost at same time, meaning units will spawn close enough together to influence each other’s pathfinding), runs ahead, activates a swordrain spell right before a hostile froster that comes into firing range in this moment can fire his frost attack, passes through a snake tower’s area of effect, taking poison damage over time that almost kills the king together with a few arblasters that were just hit by an attacker’s froster’s attack and thus have reduced firing rate. Then, the king activates a heal spell to recover health, while running backwards. He gets hit by a hostile mortar/pyromancer/froster that is just in range at time of mortar’s decision to attack/launch a projectile, but already far out of range at the time the projectile actually impacts (still taking the damage), and he is able to barely escape an ogre’s attack by “jumping” to the side in the very last moment.

 

On a replay those 10 seconds could end completely different with even tiny rounding/accuracy/timing/whatever errors. Let’s just say either the king’s initially spawned troops are spawned at slightly different time, and/or behave slightly different (resulting in different time of arrival at the “front”/king, so the king’s first froster arrives a little bit later), or the king’s swordrain gets delayed by a tiny bit (hostile froster fires before) or gets activated a little bit earlier (froster still outside range). Then, the king could take a little bit more damage before he can retreat, killing him by the time he presses the heal spell, marking the end of raid on the replay. Or, maybe the mortar/pyromancer/froster picks a different target this time and the king survives, or the king doesn’t escape the ogre strike as the input leading to his “jumping” out of the way is slightly mistimed or inaccurate or is just made meaningless by the this-time frost-slowed hero, making him have considerably less hitpoints than originally, making him die later when he was at 25% health in the original raid… and that is just what could happen in 10 seconds. I BET that probably over 90% of all raids would be quite different from the original in their replay results after a full length of 2:40min or 160 seconds. Even worse, you couldn’t even state “ok, that attacker died after 30 seconds”, because it could be just the slightly wrong replay that caused the death, while the actual attacker ran out of time or died at a later point… so, in the end a input-based reinstallment of a raid is not suitable for learning where or why attackers fail in your base, or why they get through.

 


 

Having said this, I definitely am a fan of the idea of improving after-battle reports. Adding something like a “reason for death(s)” icon/display, and especially a time value to get an impression of how easily/quickly the attacker beat a base or ran out of time.

hi heroesflorian,

yes you need the start settings. maybe some other informations too. however in other games it is feasible. it simply works with less data than a video and usually it was possible to adjust the view/camera perspective in the replay. simply a great feature. would also be great for troubleshooting/debugging the game.

Great idea! Cant be that hard, have a look at games like COC of Boom beach…Works great!

They have stated a while back that a video recording will not be happening due to data issues or something along that lines, other games can do it but they are not as data heavy as RR2 I guess. I do not know. This will not be coming any time soon, sadly for those that want it the best you have is testing your own defense and trying to replicate how they attacked you.