Please Remove Battlefield Scaling! Use Click-and-Drag instead!

[DeletedUser]

[...] it weakens older age units and rightly so as you wouldnt expect a knight to withstand an attack from moden weapons so for that purpose i think it works well.

I'm sorry, but that statement makes no sence at all. Scaling does not weaken any units. The only thing scaling does is to confuse people because a "larger" battlefield has the same *size* as a smaller battlefield. In other words, 1 meter that got scaled down resulted in 1 meter... Wait, what?!?

I respect if you don't find the scaling confusing, but please remember that this threads main purpose is to request a scrollable battlefield, with or without an option to turn it off in the settings. Please do not try to turn the thread into "we have changed our minds, the scaling is good", because that is not the case, atleast not for all of us. If you do like the scaling and want improvements to the scaling itself, please consider creating a separate thread for this request.

I would like to turn this thread back to it's original topic:

Some of does not like the scaling, and find it really, really confusing. Obviusly, we who doesn't like it, fight a lot every day and therefore this dumb scaling is sort of gamebreaking (for us). Therefore, it would be great if we could get an option to use a scrollable battlefield, which can be turned on in the settings. You who likes the scaling doesn't have to worry, because you'll still be able to use it.

However, we who would like a scrollable battlefield would greatly appreciate if this could be implemented. Please?

 

[DeletedUser]

I think scaling is a better solution then click-and-drag.

First, implementation of click-and-drag method would require a lot of programming, and we all know that FoE has the best in the world designers, but only amateur programmers Imagine how many new bugs will appear with click-and-drag.

Second, click-and-drag technique would lead to frequent "misclicks", when you wanted to drag the battlefield, but instead clicked and your unit moved to a random spot. Imagine frustration caused by such "misclicks".

Third, larger number of hexes with "click-and-drag" maps would increase load on servers (larger lag) and probably would require modification of AI. Devs pretty much nailed AI in the current version, but I doubt it will work as well with larger maps.

Fourth, and most important one: Scaling is a permanent solution. Devs can add now any number of ages, with ever increasing scaling ratio. Click-and-drag can, probably, work in PE, although trying to move your unit in attacking position while keeping it out of the range of another unit could be difficult sometimes. But in the next ages (where, supposedly, units will have even larger ranges) it would be absolutely impossible - you can't fight if you see only 10% of the battlefield.

BTW, everyone can try kinda click-and-drag method right now - just resize your browser window so you'll see only half of the battlefield. Then try to fight constantly scrolling the battlefield.

What is really needed is a better highlighting in the battlefield. We should be able to see attacking range of enemy units, not remember stats (and, now, - scaling) and count hexes.

 

[DeletedUser]

Please do keep the thread on topic. I respect that some people like the scaling, but this thread is not aimed towards improving the scaling, but to request a scrollable battlefield. Also, it's totally fine to argument against any suggestion, but please base your arguments on facts and real information when doing so. I'm sorry to say, but many of your statements (if not all) makes no sence at all.

First, implementation of click-and-drag method would require a lot of programming, and we all know that FoE has the best in the world designers, but only amateur programmers Imagine how many new bugs will appear with click-and-drag.

No, it would not require a lot of programming, and I'm talking from my own experience. The Click-and-Drag feature already exists ingame in the city view. Implementing this for the battle view would mean mostly copying of old functionality and then adjust it for the corresponding methods and classes in the battle view.

Second, click-and-drag technique would lead to frequent "misclicks", when you wanted to drag the battlefield, but instead clicked and your unit moved to a random spot. Imagine frustration caused by such "misclicks".

It would be really great if you could read the opening post before answering. I'm not asking you to read all replies, but reading the OP isn't too much requested, to be honest. I'll answer this by quoting myself from my OP-post in this thread:

[Note] For the ones that think that this will cause a too high risk for "accidental clicks":
There's loads of ways to don't risk to click by accident. For instance, you can click-and-drag on a piece of water, there you won't be able to move or attack by mistake. If there is no water, which is pretty rare, you would always click-and-drag on a square that is outside your current selected units moving range and not on top of a hostal unit. There will then be no risk to click by mistake.

Third, larger number of hexes with "click-and-drag" maps would increase load on servers (larger lag) and probably would require modification of AI. Devs pretty much nailed AI in the current version, but I doubt it will work as well with larger maps.

Do you really think that each hexagon communicates with the server? If that would be the case, the game would be unplayable for players with slow internet connections with the small grid we use today. This just shows that you lack knowledge about how game-to-server communication is constructed, still you decide to use it as an argument...

When a player attack someone the players client asks the server (database) about what 8 units that is stored in the defenders army. Then the battle start. The AI runs locally on your computer. When the battle has finished, functions get called to register values depending on the battle result. The attackers casualties, score etc. If the player bails from a battle, a temporary log is stored on the database which holds all units current positions. That is just an entry with 16 values, 1 for each unit. A battle replay is stored as an array with 16 values. So, a battle with 10 turns would result in an array consisting of 160 values (16 values * 10 turns).

So, as you see, the size of the grid does not affect the server load because the updating and drawing for a battle is run locally (on your computer). A larger grid would require a faster computer though, that's why I suggested to keep the scaled battlefield as a low-spec alternative.

Fourth, and most important one: Scaling is a permanent solution. Devs can add now any number of ages, with ever increasing scaling ratio. Click-and-drag can, probably, work in PE, although trying to move your unit in attacking position while keeping it out of the range of another unit could be difficult sometimes. But in the next ages (where, supposedly, units will have even larger ranges) it would be absolutely impossible - you can't fight if you see only 10% of the battlefield.

Once again, you're thinking the direct oposite.

Scaling is a TEMPORARY solution. Currently 1 PE square is 1.5 "ordinary" squares. This means that the range of a non-PE unit is divided by 1.5, and then rounded up, on a PE-battlefield. Some examples below:

Rifleman: 8 squares / 1.5 = 5.33 = 6
Jeager Infantry: 6 squares / 1.5 = 4
Grenadier: 2 squares / 1.5 = 1.33 = 2

Ok, this works with the 1:1.5 scale for PE. What happends in later ages if they want to use a 1:2 scale? Let's see:

Rifleman: 8 squares / 2 = 4
Jeager Infantry: 6 squares / 2 = 3
Grenadier: 2 squares / 2 = 1

Problems already occurs when they will use the 1:2 scale, and you call this a permanent solution?

What will happen when they use an even larger scale? 1:3? 1:4? Oh btw, when they use 1:4, mounted archers will become melee and snipers will get a range of 3...

BTW, everyone can try kinda click-and-drag method right now - just resize your browser window so you'll see only half of the battlefield. Then try to fight constantly scrolling the battlefield.

Not really. If they make their browser window smaller, they will get a visual grid with a width of just few squares, which would result in massive scrolling.

A full sized window scrolling would have a width of 23 squares. 23 squares width would allow a player to see the full range of all units, even artillery have just a range of 15 squares. This means that artillery would be able to have a range of 25-30 squares, and the scroll system would still work well, because the range is painted on the ground, so it's not necessary to see the current unit in the viewport.

What is really needed is a better highlighting in the battlefield. We should be able to see attacking range of enemy units, not remember stats (and, now, - scaling) and count hexes.

Please read my previus post. I respect that you like the scaling, but please keep this thread on topic. This threads purpose is to request a scrollable battlefield as an alternative to scaling. If you want to suggest improvements to the scaling, please do create another thread for that.

Once again I would like to point out that I'm not saying that anyone is wrong here. We all play the game in our own ways. Some like scrolling, some like scaling. But please stay on topic, this is not the place to discuss improvements to the scaling.

Therefore, a begging Please to the devteam: Could you please add a click-and-drag scroll to the battle view? It would be a great addon for the game

 

[DeletedUser7719]

Thanks for your input The Countess.

Is a larger grid with click-and-drag scroll something that you would consider implementing or would that count as "sweeping changes"?

It's a sweeping change

It's an interesting idea though, but not something that is likely to be considered for the immediate future (would take loads of time to implement something like that).

You got an answer. I don't see why this thread needs to continue anyways...

 

[DeletedUser]

You got an answer. I don't see why this thread needs to continue anyways...

Because, as responded:

It's an interesting idea though, but not something that is likely to be considered for the immediate future [...]

It is an interesting idea, which would be a great addon for the game, and it would be nice to discuss the positive things (and negative things) with adding a feature like this

The Countess said that it shouln't be considered for the immediate future, so my question is if it will be implemented in any upcoming/future updates?

 

[DeletedUser7719]

Yea, but remember she said it would take loads of time to implement it, so is it simple to code: no, but I wouldn't be surprised if this changed when the next era comes out

 

[DeletedUser]

Please do keep the thread on topic. I respect that some people like the scaling, but this thread is not aimed towards improving the scaling, but to request a scrollable battlefield....

Strange position. So, everyone who doesn't like your idea should shut up and then you can tell that it was unanimously supported?

No, it would not require a lot of programming, and I'm talking from my own experience. The Click-and-Drag feature already exists ingame in the city view. Implementing this for the battle view would mean mostly copying of old functionality and then adjust it for the corresponding methods and classes in the battle view.

If you have programming experience, you can see a lot of bugs here that show amateur level of programming (no offense to devs). Just the last one - wrong division in the scaled map that results in highlighting units that you can't attack. I don't believe major change of battle system can be done fast and without serious bugs.

It would be really great if you could read the opening post before answering...

You are telling what can be done to prevent misclicks. I'm telling what will happen. Do you think all players will look for a water hex every time they need to drag battlefield? Where will you find a hex outside the range of (PE+2 ages) fast unit? You can also propose that all players buy 29'' monitors so the whole battlefield will fit

Do you really think that each hexagon communicates with the server?

Do you really think I'm an idiot?

If that would be the case, the game would be unplayable for players with slow internet connections with the small grid we use today. This just shows that you lack knowledge about how game-to-server communication is constructed, still you decide to use it as an argument...

Yes, you do. Well, I disagree with you, so I'm an idiot by default

Maps are generated and stored on the server. Larger maps = larger load. It might (should) be a minor thing, but somehow battles manage to lag even now. See my #1.

As for the local effect - you told it yourself:

A larger grid would require a faster computer though, that's why I suggested to keep the scaled battlefield as a low-spec alternative.

Scaling is a TEMPORARY solution. Currently 1 PE square is 1.5 "ordinary" squares. This means that the range of a non-PE unit is divided by 1.5, and then rounded up, on a PE-battlefield. Some examples below:

Rifleman: 8 squares / 1.5 = 5.33 = 6
Jeager Infantry: 6 squares / 1.5 = 4
Grenadier: 2 squares / 1.5 = 1.33 = 2

Ok, this works with the 1:1.5 scale for PE. What happends in later ages if they want to use a 1:2 scale? Let's see:

Rifleman: 8 squares / 2 = 4
Jeager Infantry: 6 squares / 2 = 3
Grenadier: 2 squares / 2 = 1

Problems already occurs when they will use the 1:2 scale, and you call this a permanent solution?

What will happen when they use an even larger scale? 1:3? 1:4? Oh btw, when they use 1:4, mounted archers will become melee and snipers will get a range of 3...

I don't see any problem with ranged units turned into melee when fighting in several ages ahead battlefield. Really, it doesn't bother me at all. In Space Age everything with range below 1 parsec is melee

 

[DeletedUser]

You got an answer. I don't see why this thread needs to continue anyways...

lol, this is exactly what I was thinking too while I was skimming to catch up on the thread and saw the "please keep it on topic".

I respect your idea falcon, it's a good one..but i'm not sure that it's necessary. Unfortunately, it doesn't look like it will happen as Countess mentioned already. I think what we will see is just a change in range stats. It's a quick, simple solution to a problem that really isn't that huge of a problem to begin with. If the stats had of been changed with the scaling, there probably wouldn't have been any confusion to begin with. I honestly see your suggestion for battlefield scrolling more of a potential add-on feature that could prove worthy at some point in the future, rather than a fix to the whole scaling confusion...

...With that in mind, you have every right to continue the discussion on it if you please. However, I suggest you maybe post a thread in the "ideas" forum with a template and the whole nine yards. Reason I suggest this, I don't see much more discussion left here, so it's likely the thread will get lost in space, so it'd probably be a good idea if you remain passionate about trying to campaign for it. :-)

 

[DeletedUser]

Lol falcon I'm not sure anymore if you are trying to propose an idea or found a new religion :-P Like byeordie said, you already got an answer from Inno and now you are being even professionally offensive telling people how to code and do their job without even knowing how specific features were implemented.
On a funnier note, your interpretation of Countess' reply reminded me of a scene from Dumb an Dumber when Jim Carey asks the hot girl from the movie what are the chances of two of them ending up together. The girl replies "1 in 1 million" after which Jim Carey says "Wow, so I do have a chance!" xD

 

[DeletedUser]

Maps are generated and stored on the server. Larger maps = larger load. It might (should) be a minor thing, but somehow battles manage to lag even now. See my #1.

Do you have any proof that this is true? Because I hardly think so...

PvP-maps (when attacking a player) is randomly generated by the client, there's no need to send any request to the servers about this as the "creation" of a battlefield is random with a set of rules (not too much water etc). This is done in the client. The battle replay stores an array of ints to "remember" what the terrain looked like.

If they have made a large collection of pre-designed maps that are just randomly chosen for each battle, these maps are embedded in the client aswell. This would actually be even more efficient as the database wouldn't need to hold an array of terrain values but just 1 single int which describes the ID of that map. When the battle replay is loaded, the client asks the database for the ID, and then loads the embedded map with that ID. Simple and efficient.

All sectors have pre-designed maps. These maps are also embedded in the client, where each sector does not hold an array of terrain data, but instead a simple int that describes the maps ID. This is all done in the client = your machine = no server requests.

 

[DeletedUser]

(splitted this up in 2 posts as the text below is not aimed toward any specific person).

I don't really see the problem here? Why are some of you argumenting against something that will not even affect you? As I've stated over and over again, they can add an option in the settings to switch between a scrollable view or a scalable view. We who would want scrolling would be happy, and you who like the scaling could still use your precious scaling. What's the problem?

 

[DeletedUser]

When the battle replay is loaded, the client asks the database for the ID, and then loads the embedded map with that ID.

If you're trying to say that the maps are stored/cached on the client (more specifically i'm referring to battle replay that you've mentioned), and the client just asks the server for a "map ID" so that the client knows which cached map to load for a replay, i'm 99% positive that you're wrong on this.

If this were the case, when you clear your browser cache and temp files, you'd also be clearing the maps that you just said are stored on the client. This would mean you wouldn't be able to watch a battle replay after you've cleared your cache/temp files, and that isn't the case. You can still watch a battle replay after clearing.

I think much of your logic is flawed here regarding how the game is coded and how it functions. If what you have said was in fact how it works, then the game would take much longer to load for the first time after clearing your cache and temp files. If everything was stored on the client, it would have to rebuild everything once you've cleared it all. I have never noticed a difference in loading times after clearing.

 

[DeletedUser]

lol... not the cache, the cache is a temporary memory used for quick access, lowering loading times. If they would have placed the maps in the cache, the maps would have been deleted when you clear your cache. And yes, clearing your cache does make your loading times longer (the first time), altough it's propably not noticable on most machines because they are fast enough to make the difference minimal in a smaller game.

You have mixed up two tems here. The client is not equal to the cache. The client is the .swf file embedded in the website. The client is the application that covers the whole webpage and in which you play the game.

The maps are embedded in the .swf file, either directly in instances of map objects connected to the games code, or in some linked files or directories, depending on how they have designed it. When the game needs a map, it randomly choose one and loads it from the client (either a linked separate map file, or an instance of a map object), not from the database! What a waste of bandwidth that would have been.

 

[DeletedUser]

I'm very aware of what the cache is. It's your terminology that you present unclear and incorrectly. The "client" computer in this case would be OUR computers. A client is a computer or device used to access and view files. The server hosts the game. Our computers access the server. Just like client computers in an office access files on a server. The way that you explained things above was as if you were suggesting that the client...our computers...store/cache game files, which they don't. Also, i'd be willing to bet that the files are not embedded in the .swf, either. If they were, the .swf would be an outrageously huge file, and would take far longer than the 5-10 seconds it takes to load. I'm pretty sure we're working off mostly actionscript communicating with mysql databases. It feels more like the .swf we play off is more of a viewer - of sorts - than anything (although not entirely, because if that were the case, clearing our cache wouldn't improve anything, and it does a lot of the time, so something does cause the cached swf to grow). Some flash banners on websites take longer to load than FOE does, and that's typically because images displayed on those banners are embedded in the .swf file itself, and those .swf files can get huge real quick unless the file is compressed with really sacrifices quality. I just don't see that here.

 

[DeletedUser]

When we see the loading screen, the .swf file is being (down)loaded from the server into your browsers cache. That is where the major serverload occurs. The .swf file that has been (down)loaded into your browsers cache holds all graphics, sounds and external files that the game needs. That is why there's a loading screen, simple classes without any assets wouldn't require any loading as they would have loaded within 1-2 seconds.

It's pretty fun that you're trying to tell me that each separate graphic and sound are loaded into the game when needed and not upon start. The time we wait for a city to load is the time it takes for the computer to assign the correct textures to each object (textures that are already downloaded), imagine the amount of time it would take to download each individual image from the server. Imagine when a players decides to go mot/pol all players all his guildies. Imagine when 30-50 players decides to mot/pol or attack + plunder at once. The server would be overloaded if it had to return textures every 1-3 seconds. Instead, each player that starts the game, loads all required assets (which is placed inside the .swf) upon start. 1 compressed package is downloaded, then extracted in the client.

 

[DeletedUser]

I really think you're wrong here. If all content was preloaded in the initial loading of the swf, it would take longer to load. There's no way it loads all content that quick. Like I said, i've seen, as well as designed, simple flash banners/flash content that take longer time to preload than this game does.

If all images and content were preloaded, it wouldn't take a few seconds to load other player's towns when we visit, or other content of the game like the continent map, battlefield, etc. Also, the game would not slow down the more you play without refreshing. Why else do you think it begins to slow down and take longer to load? The cached files begin to pile up the more you play because more and more content is loading and caching. More evidence that points to this being true is once an image loads the first time, say a specific building, it's then cached and doesn't require re-downloading the next time that image is called on (unless you've refreshed). So if you have a ceramics factory in your town, it's loaded that image already and won't need to be reloaded if you visit another town with a ceramics factory. I've always assumed this was one of the reasons why we don't have the option to rotate buildings. If we did, that'd be double the graphic files that would require loading (one for each rotation view).

 

[DeletedUser]

PvP-maps (when attacking a player) is randomly generated by the client, there's no need to send any request to the servers about this as the "creation" of a battlefield is random with a set of rules (not too much water etc). This is done in the client.

If battlefield generation/selection or AI or random damage calculation would run on the client than it would be possible to cheat by tampering with swf file. These tasks must run on the server.

 

[DeletedUser]

I really think you're wrong here. If all content was preloaded in the initial loading of the swf, it would take longer to load. There's no way it loads all content that quick. Like I said, i've seen, as well as designed, simple flash banners/flash content that take longer time to preload than this game does.

If all images and content were preloaded, it wouldn't take a few seconds to load other player's towns when we visit, or other content of the game like the continent map, battlefield, etc. Also, the game would not slow down the more you play without refreshing. Why else do you think it begins to slow down and take longer to load? The cached files begin to pile up the more you play because more and more content is loading and caching. More evidence that points to this being true is once an image loads the first time, say a specific building, it's then cached and doesn't require re-downloading the next time that image is called on (unless you've refreshed). So if you have a ceramics factory in your town, it's loaded that image already and won't need to be reloaded if you visit another town with a ceramics factory. I've always assumed this was one of the reasons why we don't have the option to rotate buildings. If we did, that'd be double the graphic files that would require loading (one for each rotation view).

There's not that much assets. Apart from 2 larger background textures there's only smaller textures. An asset is not loaded for each object, but instead the same asset is used for multiple objects, the same applies with avatars and icons. For instance, if your city has 20 high-rises, the texture for those 20 houses are not loaded 20 times, but only once.

I've been programming for 4 years. I program applications for my own use and also 2D games as a hobby, currently 4 finished 2D games. I'm also studying Computer Science to become a Software Engineer. I know what I'm talking about

With that said; I can't guarantee how the FoE code looks like, simply because I'm not hired by InnoGames as an programmer. However, I hardly believe that they havn't done this in a similiar way. If not, I understand why the game suffers from memory leaks and bad performance for some players.

You would be surprised how fast a computer is when programmaed correctly I think that much of the graphics are stored in the cache, that is why loading times are a bit shorter. Try this:

1. Load your city.
2. Clear your browsers cache.
3. Reload the page. The loading screen will require a little longer loading. I have a very fast internet connection, but even I noticed a slight increase in loading time, atleast 3-4 seconds, and that is pretty much for a such small game as FoE.

The game crashes regulary because of memory leaks, not because the same textures get loaded over and over again. If the memory leaks is due to old textures not being released, they have done something horribly wrong because textures should *only* be loaded once per instance. I however don't think that's the case, that would be way to obvious and they would have fixed the memory leaks long ago.

Worth of note is also that memory leaks does not slow a computer down, it just makes the program crash because it has no memory left to use. If the game runs slow after time, that is propably because of some list or queue that is being enqueued but never dequeued.

The memory leaks are most likely the result of instances that are beeing crated, but never released. The resources of these instances never get released, resulting in the application slowly eating up all its allowed memory. If this was due to textures or other assets, it would have happend much quicker, but currently its possible to play for atleast 15-20 minutes before a memory crash accours, which is most likely due to instances that hasn't been released or re-used.

But as said, I'm not hired at InnoGames, nor am I hired to program FoE, so I can't tell you exactly how their code looks like. I can just say how things *should* be programmed This conversation about the technical details is actually quite meaningless unless they decide to hire us as programmers (which I gladly would like to help them with) haha

If battlefield generation/selection or AI or random damage calculation would run on the client than it would be possible to cheat by tampering with swf file. These tasks must run on the server.

lol! And how would you like to get access to the .swf file in order to tempering it? Prove your argument and tell me how you are able to even get access to the .swf file? haha

(by now I hope you realise how dumb your argument was)

 

[DeletedUser]

I'm not going to read that whole post. I got through the first few lines and you're just repeating things you've already said, as well as things i've already said. For the record, if we're going to credential drop here, I have my BA in Computer Engineering from UCF, and i've been web and flash programming for over 11 years now (although recently i've moved away from flash and into html5).

All you did in those first couple paragraphs were repeat exactly what I just explained about reusing cached images. However, you're downplaying how much is actually required to load. I'm not going to sit and argue this with you because neither of us know how this game is coded, and there are several possibilities. That being said, I still fully believe you're wrong.

 

[DeletedUser]

lol :p As I wrote in the end:

But as said, I'm not hired at InnoGames, nor am I hired to program FoE, so I can't tell you exactly how their code looks like. I can just say how things *should* be programmed This conversation about the technical details is actually quite meaningless unless they decide to hire us as programmers (which I gladly would like to help them with) haha

Let's leave it here


------------------------------


And for the rest of this thread, I would just like to remind:

I don't really see the problem here? Why are some of you argumenting against something that will not even affect you? As I've stated over and over again, they can add an option in the settings to switch between a scrollable view or a scalable view. We who would want scrolling would be happy, and you who like the scaling could still use your precious scaling. What's the problem?