zoot
-
Posts
1.557 -
Joined
-
Last visited
-
Days Won
9
Posts posted by zoot
-
-
Why not with a position? The attack does take place at a position after all
Because that would defy the point of an attack notification. You want to hear it regardless of where the camera is pointed, not only when you are already looking straight at the battle.
-
I like the current system
It's straightforward, and doesn't lead to counter-intuitive cases like a wooden shield absorbing 50% of the blast from a nuclear bomb.(Speaking as a player, though, not as someone having done any gameplay programming.)
Armour does not work in that simplistic way. It has massively varying strength depending on where and how you hit it, many places on the body have no armour. Lighter armour is effective in some situations because you can move more rapidly and take less damage that way, so armour should not be a literal interpretation of just the materials that a person is wearing.
I actually don't see how this relates to whether the armor value is a percentage or not. Even if the value is a percentage, it is still the same percentage being subtracted, regardless of "where" the attack hit.
-
You can play sounds, but at the moment you can't play a sound at a position without a unit. I can put that in though, I was also going to add a playlist capability for the next alpha.
Just to be clear, what we'll need for attack notification is the ability to play a sound without a position. That is, in the same way as music, but obviously separately from it (playing an attack notification sound should not interrupt the music etc.)
-
How would a color blind person know what blue is if he hasn't seen it? His 'blue' would be conditioned by our blue right? So it would correspond to the same color... Unless of course, he wasn't born colorblind and knows what blue looks like
My comment was in response to the suggestion of having an in-game option that would allow the user to make e.g. red show up as e.g. blue.
-
ERROR: JavaScript error: simulation/ai/common-api-v3/utils.js line 10
TypeError: a is undefined
SquareVectorDistance((void 0),[object Array])@simulation/ai/common-api-v3/utils.js:10
([object Object],[object Object],[object Array])@simulation/ai/qbot-wc/attack_plan.js:676
([object Object],[object Object],[object Array])@simulation/ai/qbot-wc/military.js:562
([object Object])@simulation/ai/qbot-wc/qbot.js:218
([object Object],[object Object])@simulation/ai/common-api-v3/base.js:128
@:0This was on the Atlas Mountains random map, tiny, 1 Aegis Bot opponent, standard settings.
-
I just tried it. It worked well for some time, but then it began printing an error endlessly. Should that be reported somewhere?
-
Dynamic AI, in the contest of what I want to do, is based on skill learning and dynamic scripting and has nothing to do with runtime compilation. As an idea consider a C++ coded AI, with rules stored in a file on HDD and AI decides which rules to execute. To be dynamic, any action can be executed via different rules, and the AI selects one of these relative rules based on a calculation at runtime. Moreover, the AI becomes adaptive by learning from the player.
Seems that the only thing that really needs to be C++ is the interface to the HDD. All the actual AI logic could still be JS.
If you chose to do it this way, I believe we would be more likely to be able to use your results too, since we need to keep as much code in JS as possible, for moddability etc.
-
having both arms free until enemies are within a certain range would look cool, but that'd be a whole lot of work.
Actually, that should be relatively easy, since shield and weapon are just props (separate meshes) that can be turned on and off at will.
-
Yes! It seems much improved, but I still think we could do away with all the dying sounds. Not only because they're repetitive and we need more variety. Preferably we've have a different set of sounds for battles and skirmishes. In a skirmish you might want to hear an individual unit die, but in a battle you want to hear war cries, trumpets sounding, and then trampling feet, stuff like that to make it feel epic. Think of battle scenes in a movie, what do you hear? But even in a battle I suspect there would be a special indicator sound for certain units dying, like a hero for instance, maybe mourning/lamenting sounds?
That's a pretty interesting idea, though nixing death sounds completely may be a bit drastic in my view. Perhaps they could be more subtle, blending into the other sounds you suggest, though.
-
Mods, in the usual sense, are JS only. But AIs are not necessarily part of a mod.
But you are right that it doesn't really fit the pattern of striving to keep mod-specific stuff out of the engine. agapsguy doesn't necessarily intend to follow that pattern either, though.
-
Don't forget that Hannibal was blind in one eye.
Also i'm going to submit a hannibal variation where he only has one eye
-
What you want to do is at least ambitious as well as problematic because it does not fit to the overall design with mods and simulations (both done in js) AFAIK.
Simulation components can be done in C++ (the AI manager is itself an example of this), so it shouldn't be completely impossible to extend it to support C++ AIs.
-
Others are much more informed on this than me, but have you inspected the AI manager?
https://github.com/0ad/0ad/blob/master/source/simulation2/components/CCmpAIManager.cpp
-
stwf, on an unrelated note, is there a way to play UI sounds for e.g. attack notification? There is a simulation function called PlaySound(), but that is always tied to an in-world entity.
-
1. If you can take your game and translate it into grayscale and it's still playable, then you're pretty much guaranteed no color-blind person will have a problem with it. You don't have to go that far, of course (and it may be difficult to go that far), but it doesn't hurt to try it and see how close you are (and can show you whether there's some areas you need to look at in more detail, or some areas you really don't need to worry because you're fine)
This seems like a good, practical rule of thumb. Obviously we can't make every shade in every texture perceivable in grayscale, but it ought to be possible for the most critical UI elements like the minimap, health bars etc.
-
In which file on what line?
simulation/components/Attack.js:435
var cmpPosition = Engine.QueryInterface(this.entity, IID_Position);
You have to double-click on the stack frame.Yep, that did the trick.
-
Did some testing:
Displays local variables, the "this" object and the global objectI'm not sure how the 'this' object is supposed to work? I can't find 'this.entity' anywhere, for instance, even while in break on lines referring to it.
Also, apparently if I select a different stack frame, I have to 'step' before the 'Values' list is updated? Is it not possible to interrogate the various stack frames asynchrously, while the game remains in break?
Added a "Break" commandI'm not having much luck with this. I always end up in a non-existent file called "(eval)", resulting in this error in-game:
ERROR: CVFSFile: file (eval) couldn't be opened (vfs_load: -110101)
Other than that, it looks good!
-
Well, I was responding to Zaggy1024's suggestion.The change would be having color options for each player in match setup.
And wouldn't it be easier to refer to player numbers or names instead of colors, if one of the players is colorblind?
In theory, it certainly would. What I'm saying is that I probably wouldn't want to worry about it in the midst of battle. I'd prefer if it - like so many other aspects of the game - just worked.
-
If the colorblind guy says: "attack blue", how do I know whether he is referring to my blue or his blue? IMO it's not realistic to expect random noobs to agree on such things beforehand, and it creates a poorer experience for both parties that one can never be completely sure what is meant.
"Tough luck", you might say, but then why change it all? If we don't intend to really solve the problem we might as well leave it as it is.
-
Doesn't matter the colorblind guy is going to see a different color anyways.
It's irrelevant what color he sees. The point is whether he understands the words the same way as other players.
-
Do you have any sources for this? All sources I've seen says they did not get them until the Imperial era.Onagers, sieg towers were very much present in that time. -
Doesn't look particularly uglier than e.g. the AoE3 player colors to me:
-
The game is set in the 500 BC to 1 BC timeframe.
-
Alternatively, we could limit the selectable colors to these:
New Sound Manager svn patch
in Game Development & Technical Discussion
Posted
Not sure what 'position' would mean for the sound system in that case.