maroder
-
Posts
779 -
Joined
-
Last visited
-
Days Won
10
Posts posted by maroder
-
-
On 18/10/2021 at 3:28 AM, Palaiologos said:
The thinking is that the player that would be positioned along the map border would be disadvantaged compared to the other positions
Sure, but on the other side you have the player being closest to the enemy which is also an disadvantage.
And since its an equal disadvantage between the two teams I think it's alright. (But I also don't feel that strongly about it)
-
And that you have to use a formation. It doesn't work when not in a formation.
-
1
-
-
12 minutes ago, alre said:
but pointless in the game.
Idk. I guess I would have to try it out to find out how it works) fits into the game.
-
2
-
-
5 hours ago, alre said:
that's reasonable, but any opposing army could just retreat where there is not enough space for a formation to move, and thus be invulnerable to them, until they leave formation. from there in the narrow, they could keep showering projectiles at the formation.
kind of like in real life I would say. And you can attack them with ranged units while they retreat.
-
1
-
-
1 hour ago, alre said:
hoplites fight in formation and also being balanced.
just some ideas: they could stay in formation, but only the soilders from the formation can attack that are in range of the enemy. They get an increase in armor, but also a slower movent speed.
For the testudo: makes the formation invulnerable to pierce damage, but they canot attack
-
1
-
-
I'm skeptical that with the small multiplayer base you would get anywhere near 1000 in donation and even if you did I'm not sure if this would be the best purpose of use.
Secondly you have to keep in mind that the game is not really cheat proof. There are ways to get an unfair advantage that are not detectable and such an high prize money would just be an incentive for people with bad intentions.
-
2
-
-
@Stan` I guess this does not really belong in Announcements/News
-
19 minutes ago, Stan` said:
I know, I just thought I chime in on the positive side of such a (possible) migration. Whether we like it or not, the non-opensource, big company owned GitHub is right now the largest source code host, both in terms of projects and active users. Which means that it's the place with the lowest barrier of entry for new contributors.
Sure a self hosted Gitlab is also an option, but having a place to discuss tickets/ enhancements / code ect, where I guess most of the developers these days already have an account also has major benefits.
-
just switching to a wider known and used platform like github may already lead to an increase in visibility (And by that I mean active development there, not just a mirror).
Very good article about the growth of Node.js : https://opensource.com/life/16/5/growing-contributor-base-modern-open-source
And of course: going beta so people don't mistakenly underestimate how good the game already is
-
I think it defenitly plays a role to some degree, but I posted already enough videos
feel free to investigate further tho.
-
36 minutes ago, real_tabasco_sauce said:
n your experiments, how much did map size influence lag?
did not test
-
And the other question is: would it really need a complete rewrite? From what I saw I would say that that the problematic part is the unit death / attacking combination and not all of the attacking routine. But I also would really like to hear what conclusions other people draw from the videos
-
Yeah, rewriting all that seems like a huge project, so I get that part of the argument, but personally I don't think the modability factor should play a role here (and I like to make mods).
The question is who wants to mod a game that is not functioning correctly? not doing optimization only because someday someone might want to change it seems to me like a bad tradeoff. If there are ways to optimize the javascript part that should of course be preferred, but if the only way to fix that would be to reduce some of the modability, then that is the sacrifice that has to be done (imo).
-
2
-
1
-
-
I updated the post
What I would conclude from all that (no guarantee on correctness) is that the main reason for lag (at least for me) is the overkill factor.
So the engine seems to dislike it if the health of a unit is so much reduced that it dies, but there are still other attacks incoming, which are now targeting an entity that is already dead. And this happens much more often when ranged units attack vs when melee units attack.
All other parts, be it graphics, short and long range pathfinder ect, seem not too bad from these tests.
-
1
-
1
-
-
Hey all,
mostly out of curiosity I tried to simulate a few different scenarios to find out what parts of the code contribute the most to the lag and should be considered first for future optimizations.
All this was tested with svn rev 25963 and about 500 to 600 units for each test.
TLDR: Most of the things I tested worked better than I thought, but the main problem on my system seems to be unit death
(and potentially overkill)and range queries of attacks and especially of missed projectiles. Also: the current AI implementation: See https://code.wildfiregames.com/D3769_____________________________________________________________________________________________
1st test: long range pathfinding with one type of unit
result for me: not that bad actually very little lag 1/10
----------------------------------------------------
2nd test: long range pathfinding with multiple unit types (graphic influence)
result for me: also good, very little lag 1/10
----------------------------------------------------
test 3: melee combat with 600 units |
result for me: noticeable lag 7/10
----------------------------------------------------
test 4: ranged combat with 600 units
result for me: without having a good measurement I would say the most lag so far 10/10
----------------------------------------------------
test 5: ranged combat with 600 units but emphasis on the projectile calculation
result for me: nearly no lag 1/10
----------------------------------------------------
test 6: ranged combat with 600 units but emphasis on the overkill factor
result for me: huge lag 10/10
----------------------------------------------------
test 7: gathering & short pathfinding
result for me: nearly no lag 1/10
----------------------------------------------------
test 8: BuildingAI
result for me: nothing 0/10
To gather all the information of this thread in one place:
see explanation by @wraitii to why this may be:
18 hours ago, wraitii said:For what it's worth, I'm pretty sure that the speed difference is because missing arrows query units around them to try and find alternative targets, whereas successful arrows don't. The former is obviously much slower. Thus why it seems like 'overkill' is the problem, but it's in fact just that missing arrows are computationally expensive (and every arrow after the target has been killed misses).
You'd probably notice different results if you used an attack with splash, since splash does range queries anyways (as in, just much more lag all around lol).
See https://code.wildfiregames.com/source/0ad/browse/ps/trunk/binaries/data/mods/public/simulation/components/DelayedDamage.js$71I think you're also compounding the results by having a massive blob of units nearby, since that probably slows down the C++ range query.
Overall, there is little easy gain to make here unless we got much smarter about immediate range queries.
-
4
-
-
I can't find anything in the mod.io docs about such an error
-
Iirc the problems for them are mostly red and green. So yellow should be fineEdit: No they aren't. Here is a tool to simulate colorblindness: http://hclwizard.org:3000/cvdemulator/
But they actually already have an hard time between the red "you can't afford that" buttons and the green "this is produced" buttons
Mhh not sure how to fix this.
-
2 hours ago, Freagarach said:
I don't think only greying out looks distinctive enough for quick recognition.
mhh yes, I agree.
How about yellow? Is a bright color so easy to recognize and its intermediate between "green" <- can produce and "red" <- can't produce. And you can still see the item that is paused.
-
3
-
-
I would say just grey it out (inclusive the green progress bar)
If you want to use an icon on top maybe this one could work:
Or take something like this:
-
Or add a fence around the house so it is clearer why it has a bigger footprint. Since (I guess) many people had some kind of animal back then, they maybe also liked to fence their property to make sure the animals don't run away.
-
I mean we could make the footprint sizes for these buildings for the celts the same (could work for houses, farmstead and storehouse) Maybe adjust the model size a little bit so it doesn't look too off.
Or just as an idea to also include forge, market ect. We could group multiple of the small houses into one "multiple house building" and increase price and population space accordingly. Should have roughly the same footprint size then, but will also have implications for the early game.
Alternatively we could just increase the footprint of the small houses to be really big for them with the argument: houses need space in-between so people can reach it.
-
1 hour ago, Freagarach said:
One of the original ideas would be that one could build houses and the houses can be upgraded into e.g. a forge, or a market, instead of directly placing one.
Do you know why this was not done in the end? Was there a discussion deciding against it or just time constraints?
-
You could try and just search for "interestinglog.html" maybe it just got saved somewhere else.
-
On 09/09/2021 at 3:44 PM, alre said:
I can keep making improvements if you like, my goal is to make formations good looking, and also reasonable even for competitive games, and I'd like my edits to go in the main game.
coming back to the original topic here
I still like the formation behavior in your mod. Why don't you make a patch so it can be discussed if/ how this can be integrated in the main game?
-
1
-
With stronghold team placement, distance to map border may need increasing
in Gameplay Discussion
Posted
a bit too complicated to do this just for one map I guess