'Very Easy = too hard' frustration.

[DanW58]

Another thing that could be done to vastly improve the game difficulty is to make wild animals easier to kill.

I just started a game (Alpine Mountains (3) at Very Easy), with one enemy and one ally.

After only 2 or 3 minutes, I've already lost the game, for all intents and purposes, because of the ridiculous amounts of time I have to devote to keep my calvary alive while fighting dozens of wolves;  I haven't done anything at all to grow my colony;  any map where there's wolves or tigers or lions are basically maps where a beginner is GUARANTEED to lose.  The outcome is 100% predetermined.

I have to manually retreat and attack again roughtly 4 to 6 times for each wolf;  it takes forever and I can't deal with production and units and research while doing that;  or have an option for no wild animals, perhaps;  I HATE THEM, personally;  I don't see what they add to the game, except frustration.

 

EDIT:  Please see my previous post also;  the last post in previous page.  That one is a coding offer.

 

EDIT2:  Started another game, another map.  In this one, right at the start of the game, I get a Roman soldier out of nowhere and killed half my women in the time it took me to figure out WHAT was attacking me WHERE;  I could not even see the attack;  only hear the horn.  Exit game again.  It is pointless...  Perhaps it is true that using an allied AI should make things easier;  but to have an allied AI you have to use a 3-player map, and so far the 3-player maps are all impossible to play.  The first one I tried did not have enough flat terrain to build farms.  The second was infested with wolves.  The third one has passing Roman soldiers that totally destroy you from the start....  This is entirely pointless.

Let me guess:  Things like wolves and random Roman soldiers are parts of the map.  Right?  So they fall out of the jurisdiction of game difficulty setting?  Not good...  If you want to make magical maps, maps owned and operated by Gaia, you have to make them customizable, and hook Gaia into the game settings.

Edited January 16, 2021 by DanW58

[Stan`]

Hey,

Thanks a lot for the coding offer!

For the technical part, while I understand most of it I'll let @wraitii and @vladislavbelov tell you whether it's a good idea or even applicable to the current architecture.

Yes the threading patch for the pathfinder is still open, and there is still a long way in optimizing it.

• https://code.wildfiregames.com/D14 (Pathfinder Threading) We might need a thread pool for this and to rethink our entire usage of threads.
• https://trac.wildfiregames.com/ticket/3290(Enabling the JPS cache for the pathfinder)
• https://trac.wildfiregames.com/wiki/GSOC_Ideas (Some ideas for C++projects)

We recently merged https://code.wildfiregames.com/D2848 for which you might have some interesting suggestions.

First I think you need to familiarize yourself with the contribution process. I'd suggest you to get the source code and trying hacking it around. See wiki:BuildInstructions

Then I'd suggest you'd look into the contribution process wiki:SubmittingPatches as it might be a bit surprising to you, namingly the usage of Phabricator wiki:Phabricator

If you're interested in SIMD as well, we had some trouble with MSVC doing a crappy job at vectorizing so we have patch like this one lying around D2857 and that forces us to keep some code as depicted in https://code.wildfiregames.com/D3212

6 hours ago, DanW58 said:

I just started a game (Alpine Mountains (3) at Very Easy), with one enemy and one ally.

It's one of the special maps where there are triggers. @FeXoR or @Freagarach might be able to do more about it.

Please feel free to reach out to me, or to us on irc #0ad-dev channel. You seem to be on a different timezone, but we read the logs at  irclogs.wildfiregames.com/ so you can ask your questions there and we'll respond when we can.

 

[DanW58]

Thanks for the thorough answer.  I just had a random poke at the D2857 folder.

If I understand anything, it seems you're trying to let the compiler write SSE for you.

When I worked with SIMD (that was not SSE;  it was 3DNow! by AMD, which preceded Intel;  but it's basically the same thing, as Intel basically copied AMD's 3D Now! with a few changes here and there), I did it all by hand, in Assembler.   My .h files were all pure C++, using templates and all;  but in my .cpp file, every function went like
 

{

   #asm:

       {SIMD code}

   #endasm

}

It was a 3D vector, matrix and quaternion math library.

No compiler touched SIMD back then, but I wouldn't have used it if it had.

The most surprising thing was when I wrote code to test the functions, and discovered that in the entire library there was just one single bug;  a typo, at that.

Usually the make-believe is that higher level languages are supposed to reduce errors in code;  I found the exact opposite.

In terms of performance it was lightning fast;  not 4 times faster;  more like 15 times faster than non-SIMD code.  Probably 25 times faster when looping it over arrays, thanks to prefetching;  but I didn't test that.

 

 

[Nescio]

9 hours ago, DanW58 said:

Another thing that could be done to vastly improve the game difficulty is to make wild animals easier to kill.

I just started a game (Alpine Mountains (3) at Very Easy), with one enemy and one ally.

After only 2 or 3 minutes, I've already lost the game, for all intents and purposes, because of the ridiculous amounts of time I have to devote to keep my calvary alive while fighting dozens of wolves;  I haven't done anything at all to grow my colony;  any map where there's wolves or tigers or lions are basically maps where a beginner is GUARANTEED to lose.  The outcome is 100% predetermined.

I have to manually retreat and attack again roughtly 4 to 6 times for each wolf;  it takes forever and I can't deal with production and units and research while doing that;  or have an option for no wild animals, perhaps;  I HATE THEM, personally;  I don't see what they add to the game, except frustration.

Thank you for pointing this out! Animal stats are a mess and have been for years. They really need a critical look and more reasonable numbers. Most maps have few of them, so it's not really a problem in most games, but it can be on some, as you experienced.

How about simply halving their health and attack damage for now?

[DanW58]

Sounds like a good, quick solution.  I know that if I wait until I have 4 cavalry, before exploring, and send them all together, they usually survive with but little damage;  so halving their health and attack damage that's over-all 1/4 of the strength, so a single cavalry could then survive.

It's not all the animals that are so bad.  The crocodiles and bears are maybe worth halving their strength;   not quartering it.  I think the worst is wolves, as they appear to be harder to hit than lions and tigers, and so take a good dozen javelin throws to kill.

Another solution that might be good to have generally is a combat modality whereby you command your soldiers to be agressive, but to retreat when injured.  Then one could send a single cavalry to explore without having to watch over it not getting itself killed.

[Stan`]

2 hours ago, DanW58 said:

If I understand anything, it seems you're trying to let the compiler write SSE for you.

 

That works pretty well with clang and GCC. The game is about twice as fast on linux because of it. But sometimes they fail as well.

2 hours ago, DanW58 said:

but in my .cpp file, every function went like
 

In our case we use the intrisics function instead to make the code more readable. Also we have to be weary of platform support e.g arm doesn't have sse instructions they use neon.

 

[vladislavbelov]

6 hours ago, DanW58 said:

In terms of performance it was lightning fast;  not 4 times faster;  more like 15 times faster than non-SIMD code.  Probably 25 times faster when looping it over arrays, thanks to prefetching;  but I didn't test that.

For our case we need to reorder high-level operations first to make it significantly faster.

4 hours ago, Stan` said:

That works pretty well with clang and GCC. The game is about twice as fast on linux because of it. But sometimes they fail as well.

It works mostly for relatively simple operations, any non-intuitive logic might break compiler's optimization.

 

16 hours ago, DanW58 said:

Is the multi-threading done, or is it still open?

We have code local threads, but we want to have a task manager (thread pool) to remove such local management.

[wraitii]

I think the main area in the simulation where memory fragmentation matters is the Sim components. Right now they're basically random, and we can do much better.

Threading in general isn't that easy because the game's architecture assumes that everything can be modified mostly at any time. There are a few things that don't (namely the pathfinder is 'easily' threadable), but most things are.

[DanW58]

13 hours ago, vladislavbelov said:

We have code local threads, but we want to have a task manager (thread pool) to remove such local management.

Alright, here you lost me completely;  I've no idea what thread pools and local management are.

 

12 hours ago, wraitii said:

Threading in general isn't that easy because the game's architecture assumes that everything can be modified mostly at any time. There are a few things that don't (namely the pathfinder is 'easily' threadable), but most things are.

Here I'm lost as well.  Okay, this is my first gut feeling how I would organize threads:

1. Kernel (a director thread using millisecond interrupts, manages simulation speed, quality, queues and thread balancing, static memory).
2. Map, resources, updates, fog of war (singleton thread with clients, all memory allocated at game initialization).  Owns path-finder lib.
3. Unit iterator thread (visits all empires, groups and units at every sim step;  calls AI client libraries, see below).
4. Projectiles, spear tips and sword edges (perhaps a separate thread from the unit iterator, as these are smaller sim objects)
5. User input, user interface (menus, etc), camera movement, positional sound (as in Starcraft, a request hint ;-) ), video synch.

If necessary, depending on test results, I might split threads 3 and/or 4 into two threads, and assign new units to them always to the thread with lesser load, to keep the balance

Client libraries to those threads would be:

• Unit and group "vision"(&hearing?)/awareness
• Path-finding
• Collision detection, accel/decel motion modifiers, for movement realism
• Empire AI, Group AI, Unit AI

Client libraries would be pure, statatic-free functions, to avoid thread-safety issues.

Such threads are only "modifiable" in the sense that units are born and die;  groups are defined or undefined, etc.;  but that's only a quantitative mod that may affect load balancing a bit...  not much at all.

If I'm understanding correctly, what you are doing, instead, is assigning groups of units to separate threads, all threads running the same code... Yes?  A horizontal breakdown, rather than a vertical one.  If so, I'd suggest a vertical approach, as a horizontal one has lots of problems.  One of them you are aware of, namely that units die (if I'm understanding correctly), affecting load balance.  But there are other problems with the horizontal approach:

• Each thread has essentially access to all of the memory, and so every thread suffers the same L1 data cache pollution as a single thread version.
• Additionally, if L2 cache is shared between cores, the L2 will be hotly contended.  In a vertical approach, each thread has its own private, smaller memory and can read and write to swapping buffers like I described in the last post of previous page.
• Each thread is essentially running all of the code, ok for L2, but making L1 code cache utilization far less efficient than it could be.
• Not using thread pipelining and swap buffers between them, allows too much freedom, leading to confusion about previous vs current vs next unit state when threads are reading or modifying each other's data,  as well as confusion in how to make class variables thread-safe.

Horizontal or vertical, having threads is a way to exploit multiple cores, primarily;  both approaches achieve division of labor.  But the vertical approach achieves additional efficiencies by reducing the amount of code AND data each thread runs or accesses, using L1 cache more efficiently, reducing contentions for L2 cache, and enforcing a cleaner organization of the code.

EDIT:

Talking about path-finding, there's a "bug" in the game (I'd call it that) whereby wood cutters search for the "nearest" depot to deliver wood to, but where nearest means sqrt( dx^2 + dy^2 ), rather than the pathfinder-nearest.  Sometimes they walk crazy distances to go to a depot across a wall or chasm before you notice and correct the situation.  You might say it adds a challenge to the game, but the challenges that add to the game experience are those that seem logical and realistic.  Nobody in the real world would be so dumb.

EDIT2:

I suggested a vertical threading approach when I was working on my own engine, back in 2000, but my partner insisted "that's not the way it's done!"

After the project was dead, an article appeared in some magazine, about John Carmack (ID software, Doom) independently discovering the vertical approach was the way to go;  and so I was right.  I was also right about my suggestion in 2000 that time be treated as data;  and that was another thing John discovered and wrote about in another article...

EDIT3:

Another problem with the game is that enemies are psychic.  They clearly have chrystal balls through which they find out I'm building a CC anywhere in the vecinity of their territory, and by the time the building is 10% complete or so they come and attack with full force.  Yet another game I have to Exit.  Super-AI's are one thing, but psychic power really has no place in games ... unless the game is about psychic powers, or explicitly involves psychers, or unless it explicitly says "civilization Z is telepathic;  beware!" (as was the case with the Elerians in MOO2).  But this business of "knowing without seeing" is anti-immersive, unfair and abominable.  Is visual field computed?  Per unit or per group?  Realistic or hacky?  Are there hacks to get around visual field for some particular purpose?

EDIT4:

Actually, I just won a game, somehow.

Edited January 17, 2021 by DanW58

[DanW58]

Another problem:  With most civilizations, a house supports 10 units;  but if you are Indian, a house supports only 5 people.

You have to spend so much time building houses you almost can't do anything else.

Of course it makes sense that there be differences between civilizations;  but a change for the worse with an item that borders on being a pure irritant by a whopping factor of two is a bit much.  Could it be made to support 8 units, maybe?  Otherwise, it's like start a game with random civ, but if India comes up, quit and start again.

There's also the consideration of real world consistency.  Are people in India more isolated than other civilizations?  Do they really accomodate less people in each house than Persians, Greeks, Romans or Egyptians?  I can't see this being the case.  My feeling is that this number, 5, was totally randomly picked.

 

[wraitii]

10 hours ago, DanW58 said:

If I'm understanding correctly, what you are doing, instead, is assigning groups of units to separate threads, all threads running the same code... Yes?

No, we're just single-threading really. The problem I was describing is that e.g. unit Motion can right now send messages to any other component, there's no "barriers".

Essentially at the moment the only things we can really thread from the rest of the game are (NB: they are not threaded yet)

- The range queries, which have their own data (but they need some clever thread pooling, starting a thread every time would be too slow)

- the pathfinder, which also has its own data

- AIs

10 hours ago, DanW58 said:

Talking about path-finding, there's a "bug" in the game (I'd call it that) whereby wood cutters search for the "nearest" depot to deliver wood to, but where nearest means sqrt( dx^2 + dy^2 ), rather than the pathfinder-nearest.  Sometimes they walk crazy distances to go to a depot across a wall or chasm before you notice and correct the situation.  You might say it adds a challenge to the game, but the challenges that add to the game experience are those that seem logical and realistic.  Nobody in the real world would be so dumb.

Yeah that's a know issue. The problem is that pathfinding is slow enough that fixing it properly was not really attainable in the past. Once the pathfinder is threaded, it'll probably be more doable.

10 hours ago, DanW58 said:

But this business of "knowing without seeing" is anti-immersive, unfair and abominable.  Is visual field computed?  Per unit or per group?  Realistic or hacky?  Are there hacks to get around visual field for some particular purpose?

The visual field (LOS/Fog Of War) is computed per player, but AIs don't use it. The problem is that AIs are designed for threading, and that requires giving them their copy of the data, and we never got around to giving them their copy of LOS data.

---

Most of the problems are known, but need a lot of rather substantial work usually. You're welcome to help  

 

[DanW58]

31 minutes ago, wraitii said:

Most of the problems are known, but need a lot of rather substantial work usually. You're welcome to help  

Gottcha.  Okay, I'll look into an IRC client, for starters  (it's been many years...)

[Stan`]

Let me know if there is anything I can do to help

[hyperion]

1 hour ago, DanW58 said:

Another problem:  With most civilizations, a house supports 10 units;  but if you are Indian, a house supports only 5 people.

You have to spend so much time building houses you almost can't do anything else.

Of course it makes sense that there be differences between civilizations;  but a change for the worse with an item that borders on being a pure irritant by a whopping factor of two is a bit much.  Could it be made to support 8 units, maybe?  Otherwise, it's like start a game with random civ, but if India comes up, quit and start again.

There's also the consideration of real world consistency.  Are people in India more isolated than other civilizations?  Do they really accomodate less people in each house than Persians, Greeks, Romans or Egyptians?  I can't see this being the case.  My feeling is that this number, 5, was totally randomly picked.

 

The number needs to be a multiple of 5 so the 20% pop bonus techs for the houses are straight forward. I agree that having to build lots of houses is annoying. With A24 you will probably have to add Britons, Gauls and Ptolemeus to Mauryan. Well, many people consider houses the primary means to build walls (rolls eyes).

Doubling pop boni for houses might be a good idea or make it 10 and 15 if 20 sounds like to much for large houses.

[Silier]

houses providing less population are smaller, cost half of resources and they build faster, i am not sure i understand the issue here

[DanW58]

So many things it's embarrassing.

I just tried a couple IRC clients.  One of them, "circle" something, installed, but didn't put itself in the applications menu;  so I uninstalled it.  I know it is probably in usr/bin or one of those folders, but it's a nightmare for me to try to find things in unix.  I know, I installed it;  no dual boot, but I'm an eternal newbie in unix.

Another I tried is "quassel" or "loque", I could not find how to list servers or channels, and had no help and no manual.  Uninstalled it.

About to try xchat....  Installs, puts itself in the menu, but I select it from the menu and nothing happens.

And I just had another killer Very Easy experience.  I was attacked by a horde of like 25 calvary.  Exit game.  Not fun at all.

Someone was saying that playing with an ally can teach me, but how can I learn when the ally is in the fog of war?

Then again, I heard there's a way to not have the fog of war, but I looked everywhere;  couldn't find it.  Just like I couldn't find the ceasefire.  Just like I don't know how to reply to an enemy offering neutrality.  A lot of things are not intuitive.

[Silier]

for irc on browser just visit https://webchat.quakenet.org/?channels=0ad-dev you do not need to have account for that

[DanW58]

2 minutes ago, Angen said:

houses providing less population are smaller, cost half of resources and they build faster, i am not sure i understand the issue here

Ah, I didn't know they cost less;  and didn't notice they built faster.  Still, even if it's a zero sum, it distracts you twice as often.

[Silier]

1 minute ago, DanW58 said:

Ah, I didn't know they cost less;  and didn't notice they built faster.  Still, even if it's a zero sum, it distracts you twice as often.

well, houses providing more pop are bigger, so they cover larger area, though civs with smaller houses would have free space advantage

[DanW58]

4 minutes ago, Angen said:

for irc on browser just visit https://webchat.quakenet.org/?channels=0ad-dev you do not need to have account for that

I'm in, but not sure what to do.

I expected to find a lot of discussion topics, though;  I just have a blank page with "(No Topic Set)", telling me I've joined.

[DanW58]

4 minutes ago, Angen said:

well, houses providing more pop are bigger, so they cover larger area, though civs with smaller houses would have free space advantage

Ah, many thanks!

 

[DanW58]

I just finished building from svn, non-debug, non-commit, and it passes the tests and runs.

However,

1)  Display has slowdown considerably.  When the game opened, the frames around windows took about 10 seconds to show.  I think it's a texture loading issue.  I started a game, and the initial map display built up slowly, as if one class of object at a time.  It could be my computer is out of memory;  I'll reboot and report back.

2)  Deer have become hard to kill, to the point that my cavalry ends up galloping half way across the map before the deer dies, which is so far away it's not even worth processing the meat.  I manually sent my cavalry to kill a deer closer to the base, and the same thing happens again:  The deer escapes fast and its health comes down slowly and my cavalry ends up almost in enemy territory before the deer dies.  Had to give up on deer hunting altogether.  Which is actually okay;  I'm vegetarian, and I hate the obligation to play as if I'm not;  but according to the tutorial videos, hunting is mandatory...

Edited January 18, 2021 by DanW58

[Stan`]

1) You're experiencing texture caching. In the development version most textures are PNG's and must be converted to DDS (S3TC) DXT1-DXT5. We do it on the fly for convenience and to make it easier test changes (All the textures are hotloaded)

2) You can build farms But yeah hunting is a bit harder. Is there something planned @Nescio
@Freagarach  @wraitii
(I mean other than the turrets patch where cavalry will be able to attack move)

[DanW58]

Ahh, gottcha.  Actually, I rebooted and run 0ad before anything else and didn't have the problem.  My computer is a bit old;  I bought it used;  4 gigs of RAM, quad Intel processor, cheap, old gforce video card.

I made the chickens pay.

Edited January 18, 2021 by DanW58

[Stan`]

Yeah textures are cached once