Jump to content

k776

WFG Retired
 View Profile  See their activity

  • Posts

    721

  • Joined

  • Last visited

  • Days Won

    6

 Content Type 

Posts posted by k776

  1. Alpha feedback

    in General Discussion

    Posted

    There is no reason Pureon's work shouldn't be the game.

    ...

    Ofcourse its useable.

    Of course they're usable and should be included. Perhaps I wasn't clear enough with my original message, so my mistake.

    What I meant last time was "Do you plan to finish them to a point where they can be committed and used ingame soon?".

    I would love to see these ingame, and usable in Atlas.

  4. Alpha feedback

    in General Discussion

    Posted

    The big question is, will these make it into the game? I'd love to have a map in the next release, which only had one player, but was an entire city, to demonstrate how nice it can be.

    Pureon, would you like to do that? Import the work you've done into the game, and then make a map demoing all the experimental scenery.

  8. AI

    in Game Development & Technical Discussion

    Posted

    Is there an example of another AI that uses a similar system to the one you're proposing?
    Not that I know of. I didn't go searching for one. I based my AI approach similar to how a browsers DOM model triggers events like mouseover, and onclick.
    Would there be any performance benefits?
    I'm not entirely sure, but I'd say it'd speed it up. As I undersand it, if you leave the current AI implementation just staying there, it has to loop over units each turn seeing what has changed and respond accordingly. It's more code, and more processing. And while not severely more, maybe enough to show notable different?

    With the event/hook system, the AI would get the info it needs. And as shown in the Pastie i sent in an earlier post, it'd only send events if the event is being listened for, so if there is no event, then nothing happens. A blank AI file would then have no extra drag on the system, and events would be much simpler for the AI writer to plug into.

    Of course, the current system could be easier maintained, and run alongside the event/hook system. But I would prefer to do it event based, as it'd make the AI much more responsive to things that happen.

    e.g. Imagine a unit is being attack, a unit just died, a building is being attack, and a unit just run out of resources to mine

    In the current implementation, you'd need to loop over every single unit, and check if their health is decreased (which means storing a list of previous units). That uses memory and time.

    With the event system, you get that info delivered to you from C++ when it executes that action, so you don't have to check, it'll know and tell you when.

    At least, that's how I hope it'll work. IT'd be great to have Philip comment on how it could actually be designed, instead of theoretical code...

  10. Got An Email About Keeping Your Account Active? Then Post Here.

    in Introductions & Off-Topic Discussion

    Posted

    I gotta be honest, I highly doubt that most of them are spam accounts. Sure, perhaps a few have slipped under the radar, but I guarantee the vast majority of them are just like the people replying to this thread.
    Are you willing to take the chance though? If a good portion of them (1k) are spam bots, 1 a day means fighting spam for 3 more years :-P

    I'd much rather do what we are, let people show activity, and delete those who don't. If anyone gets deleted and they come back, they just re-register. And that way, we can know for sure that spam from existing users won't be a problem.

  18. AI

    in Game Development & Technical Discussion

    Posted

    I've been discussing with Philip about a possible rewrite of the AI code, so it uses an event/hook system.

    I did a quick code example of how I thought it would work, here:

    http://pastie.org/1553793

    The idea is that it'll allow AI to be event driven, rather than checking every case.

    e.g. on('unit.attacked', function(unit) { defend(unit); });

    The system would be thread safe (as each AI runs in it's own thread), and it wouldn't need any serialization of the AI state, as the save game would just start firing off events again, which the AI would respond to.

    It would also allow users to write their own scripts, which could listen to those hooks, and act on them.

    e.g. on('unit.built', function(unit) { if (unit.hero) { Chat.post('Watch out, I just built a hero!'); });

    This type of thing could open up ways to all sorts of cool assistant scripts, like alerting you to an attacker, and showing a dialog to jump to it.

    e.g. on('unit.attacked', function(unit) { GUI.prompt('Jump to a unit being attacked?', function() { GUI.jumpto(unit) }) });

    Anyone have any thoughts or concerns on the matter?

  21. Graphics hardware compatibility

    in Game Development & Technical Discussion

    Posted

    Alright, then we support hardware no older than 3 years? Sounds about how long someone might have a computer before upgrading to something new.

    But I agree, we should collect user data. Something in the game, which on loading, prompts the user "Help us improve, send us anonymous usage data", send cpu, gpu etc stats. Note: It need to prompt them, we cannot(!) send data without their permission, and it should only be done once, so they load the game, and accept or deny, it shouldn't ask again when they load a second time.

    These changes should be in Alpha 4 if we want any hope of tidying up that render code in Alpha 5. If you need me to, I'll write a Rails application (or PHP, but I'd so much more prefer Rails), which can accept the data packet in JSON, parse it, and store it into a MySQL database.

  22. Graphics hardware compatibility

    in Game Development & Technical Discussion

    Posted

    Here's my two cents. Supporting old hardware is one thing, making it looks best is another. If a graphics card is too old, and doesn't support things for FOW or Shadows), the game should still run on it, but with shadows disabled, water reflections disabled, and FoW becomes SoD.

    So the idea is, the newer the graphics card, the more graphic features is 'unlocks'.

    I don't fully understand all the proposals, but sounds like #1 and #2, you could test very easily.

    if (GL_MAX_TEXTURE_UNITS < 4) {
      fow.opacity = 0;
      fow.colour = rgb(0,0,0);
      shadows.enabled = false;
      water.reflections.enabled = false;
    }
    if (!GL_ARB_shadow || !GL_ARB_depth_texture) {
      shadows.enabled = false;
    }

    9 lines of code, and you can get rid of dozens of lines of old code that tries to support rendering where GL_MAX_TEXTURE_UNITS < 4, while still 'supporting' (making it runable) on old hardware.

    As for base line requires, 512mb of graphics is pretty common these days, and most with that much RAM should support the proposals?? So it might be worth saying "minimum: 256mb, recommended: 512mb".

  23. soldiers ignoring enemy while automatically attacking building

    in Help & Feedback

    Posted

    If a unit is attacking a building, then an enemy archer comes near (into their vision range? into their attack range? into some other range?)
    Well, that right there is introducing stances. Aggressive = vision range, stand ground = attack range, and defensive = only if they attack first. But assuming both aren't implemented at the same time, the initial work should be within the closer attack range.
    should they immediately switch to target the archer? or should they wait until the archer attacks them?
    Again, stances will change this. But for now, if an enemy is within the attack range, go for him (excludes animals of course)
    When they chase the archer (who will run away)
    Not by default, but if the other player makes it retreat, sure.
    if they run into a line of enemy melee units who surround them and start killing them, should they switch to attack their new attackers, or continue chasing the archer futilely forever?
    Depends how complicated it is to find if the path to a unit is blocked. If it's simple to find out if the path is blocked (that is, they can't get to it without going into FOW, which also means enemy units who disappear into FOW stop being chased), then you retarget to the nearest, strongest enemy. Ideally, they'd know right away if they are blocked, but given the slowness of the path finder, in the case where the archer disappears in FOW because the units are surrounded and can't get to him, then the moment he's gone, they change target. That should suffice for now.
    it seems you could trick an enemy's whole army into chasing a single fast unit and then trap and slaughter them without them ever fighting back.
    Correct, and they're clever tactics, which will encourage people to focus on their units when making an attack, instead of just leaving them.
    If they should switch when attacked, then if they're chasing the archer but get shot by a second archer, should they switch to the second archer, and potentially keep alternating?
    If they are not forced (i.e. user has not specifically told them to attack that archer while they were attacking something else, command_forced = false), then they should target the stronger unit. If archer 2 is stronger than archer 1 they are pursuing, then they attack archer 2 if within range. If archer 2 is weaker, they continue with archer 1. If the units are forced to attack archer 1 (command_forced = true), then they ignore archer 2 until archer 1 is dead, at which point, the command_forced is then false (as the command was completed) and they retarget the strongest unit.

    Each attack scenario I play in my head works as I think it should using the above defined patterns and the use of the command_forced flag. I think, if implemented, it'd make the combat portion of the game much more enjoyable and useful.

    Then when stances are implemented, it'd just be some minor tweaks to what was implemented to make the above work.

  24. soldiers ignoring enemy while automatically attacking building

    in Help & Feedback

    Posted

    Agreed. The ideal automated attack order would be:

    * Enemy warriors

    * Enemy offensive buildings (town center, tower, fortress)

    * Enemy women

    * Enemy non-offensive buildings (house, barracks, farms etc)

    * Enemy unharmful buildings (walls/ gates)

    If there was something more important in sight, your units would go and attack it.

    That said, you should always be able to overwrite their target, and have it stay. A bug at the moment means you might be being attacked, and ty to retreat, but it won't retreat properly. Your units will turn around and try to fight again.

    I think:

    * If a unit is given an order, then a unit tries to attack it, it'll ignore said order and defend itself

    * If a unit is in a fight, then given an order, that unit should follow that order no matter what (even if it means he's being killed from behind while attacking a wall).

    Seems that, to implement this, you'd need three things:

    * You'd need a dynamic property on the units, "command_forced" or similar, and set to true if unit is fighting when he receives an order (i.e. you tell him to retreat).

    * Adjust the nearby unit detection code to automatically attack units, sorted by priority (as above), except if command_forced is true.

    * Adjust the unit code to set command_forced to false when the unit finishes the command he was told to do (so he goes back into defensive mode).

  25. Hi

    in Introductions & Off-Topic Discussion

    Posted

    Correct forum, no advertising on the profile, and a decent looking email address. Looks legit....

    @Chickenwings1415: Sorry for the skeptical reception. We've been having quite a few spam bots show up recently making short messages like the one you did.

    How'd you come to find 0 A.D. ?

×
×
  • Create New...