CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 2 of 4 FirstFirst 1234 LastLast
Results 16 to 30 of 48
  1. #16
    Join Date
    Aug 2002
    Location
    Madrid
    Posts
    4,588

    Re: About scanning

    Originally posted by Elrond
    I have an idea about the scanning thing. As any normal creature, they should not require time to scan ahead of them. Real creature usually don't have to stop to see what's in front of them, and then continue acting.

    I think every creature should be made aware when its turn begins of what is in front of them (say up to 2 squares in distance, like suggested by Yves M). This is not scanning but just keeping the eyes opened.

    Then there can be two types of sanning:
    The first is like making a turn aroung to see all that is around you (up to 2 squarres).
    The second allows you to see further ahead of you (like using a telescope).

    I think this would make more sense.
    Right, I agree. Requiring a separate action for just finding out what is in front of you would make creatures into blind mice Since there seem to be concerns about how the client and the server handles occluded blocks, I suggest that we leave the 'wide' scanning out of the list of moves for the time being.

    Does every creature get fixeing time slot for the next step? It must be so. Because otherwise it can spend to much time for analyzing of the next step and this is not like in true nature.
    This is indeed some concern. I guess we could set a time-out value on the server and if the creature hasn't replied back in say 5 seconds, then the server just assumes that creature sits still. But this would maybe make the client programs a bit harder.
    Get this small utility to do basic syntax highlighting in vBulletin forums (like Codeguru) easily.
    Supports C++ and VB out of the box, but can be configured for other languages.

  2. #17
    Join Date
    Jun 2001
    Location
    Switzerland
    Posts
    4,443

    Re: Re: About scanning

    Originally posted by Yves M

    This is indeed some concern. I guess we could set a time-out value on the server and if the creature hasn't replied back in say 5 seconds, then the server just assumes that creature sits still. But this would maybe make the client programs a bit harder.
    This would give clients written in C++ a huge advantage over VB, unless the timeout isn't large enough.
    Gabriel, CodeGuru moderator

    Forever trusting who we are
    And nothing else matters
    - Metallica

    Learn about the advantages of std::vector.

  3. #18
    Join Date
    Aug 2002
    Location
    Madrid
    Posts
    4,588
    That is why I propose a timeout of about 5 seconds. That should be reasonable for one turn, otherwise the whole tournament would take too much time.

    By the way, here is a small example of how occlusion would work.
    Attached Images Attached Images  
    Get this small utility to do basic syntax highlighting in vBulletin forums (like Codeguru) easily.
    Supports C++ and VB out of the box, but can be configured for other languages.

  4. #19
    Join Date
    Sep 2002
    Posts
    1,747

    rules changes

    Perhaps we can actually start with the simple rules outlined so far, and then further enhancements may be possible as outlined for particular tournaments. In other words, make a first plan to get the project runnning, and then suggest updates as we find they may improve the enjoyment of the competition. This way, we can verify the basic ideas and see how they work in practice. We may find out that some of the numerical rules for play are inadequate and can make adjustments accordingly, but they need not occur prior to the first tournament (for example, perhaps the current food rules will not be sufficient to allow anyone to win decisively, even for someone minimizing their consumption -- not that that is true, but it could possibly be found to be true, at which time a change would be needed). This means, however, that each creature can use a template provided by others, but that they may need to write their own, more generic creature if they want to robustly support future changes with reuse (much like in the real world).

    On the scanning vs. blind play issue, I think the play with requiring scannning may be more interesting (since the creature needs to make more decisions on what to assume). Call it a misty battle grid, where sometimes you need to squint .
    */*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/

    "It's hard to believe in something you don't understand." -- the sidhi X-files episode

    galathaea: prankster, fablist, magician, liar

  5. #20
    Join Date
    Jun 2001
    Location
    Switzerland
    Posts
    4,443
    Ok, don't yell at me now, but I have to say what I think:

    Don't you people want us to implement the most simple thing we can imagine and have that running before we start thinking of occluded vision, creatures that have an orientation (i.e. face N, S, E or W) and such?

    Let's have some virtual bacteries running before we try to build insects.
    Gabriel, CodeGuru moderator

    Forever trusting who we are
    And nothing else matters
    - Metallica

    Learn about the advantages of std::vector.

  6. #21
    Join Date
    Aug 2002
    Location
    Madrid
    Posts
    4,588
    I do think that occluded vision has to be there, if we allow creatures to see further than one square. It is easy to handle for the server, and not that complex for the clients. As soon as the networking is sorted out, I will try and write a sample C++ client that will hold its state information correctly.
    The concern about the facing of the creature is to allow for 'sneaky' manouvers, so that you can get attacked from behind. It does add a bit of complexity to the clients, nothing much on the server. But I do not think that it would be so hard that we need to take it off.

    Let me summarize the environment and rules I propose for the initial version:
    • Possible moves:
      1. Move forward one square
      2. Attack a creature in the square in front of you
      3. turn 90, 180 or 270 degrees
      4. Harvest food in the current square
      5. Rest in the current square
    • At initialization, the Creature tells the server how it set its stat points. There are 40 points in total, distributed in the 4 following stats:
      1. Attack strength
      2. Defense strength
      3. Food consumption
      4. Life Points

      I propose to maintain the relationships between stats that I outlined in my first proposal.
    • At each turn, the creature is told:
      1. How many life points it currently has, and how much food it carries.
      2. What occupies the 8 squares in its vision range, including the percentage of life-points of any ennemies.
    • At the start of a turn, the server sends out this information to the creatures and waits until they respond. When all creatures have responded, then the creature with the most life points will have their move executed first. If there is a tie, the selection of which one moves first is random.
    • There are four types of cell contents:
      1. empty cell
      2. wall cell
      3. food cell
      4. another creature
    Get this small utility to do basic syntax highlighting in vBulletin forums (like Codeguru) easily.
    Supports C++ and VB out of the box, but can be configured for other languages.

  7. #22
    Join Date
    Oct 2001
    Location
    Dublin, Eire
    Posts
    880
    Not perfect (obviously) but it seems OK for a first version. It seems fair to test all these values and basic rules before doing anything more.

    Al other improvements will come in time.
    Elrond
    A chess genius is a human being who focuses vast, little-understood mental gifts and labors on an ultimately trivial human enterprise.
    -- George Steiner

  8. #23
    Join Date
    Sep 2002
    Location
    Belarus - Tirol, Austria
    Posts
    647
    Great, Yves. I think that this simple model is enough good to begin to test it in a real battle.

    I want only notice that if this post set some concepts for organization, may be U post it in the "RFC", then if U need U can edit it there. This way, I've said already, we can get one place with all concepts (we will not discuss it in the "RFC"), but if someone will want to read main concepts he can read it in the "RFC" without necesary of finding them on all threads
    "UNIX is simple; it just takes a genius to understand its simplicity!"

  9. #24
    Join Date
    Jun 2001
    Location
    Switzerland
    Posts
    4,443
    Originally posted by Yves M

    Let me summarize the environment and rules I propose for the initial version:
    • Possible moves:
      1. Move forward one square
      2. Attack a creature in the square in front of you
      3. turn 90, 180 or 270 degrees
      4. Harvest food in the current square
      5. Rest in the current square

    • Move forward and attack are the same thing
    • At each turn, the creature is told:
      1. How many life points it currently has, and how much food it carries.
      2. What occupies the 8 squares in its vision range, including the percentage of life-points of any ennemies.
    ..and the direction the other creature is facing
  10. There are four types of cell contents:
    1. empty cell
    2. wall cell
    3. food cell
    4. another creature
Actually there are six:
  1. off-bounds (== outside the arena)
  2. occluded
  3. empty cell
  4. wall cell
  5. food cell
  6. another creature
Gabriel, CodeGuru moderator

Forever trusting who we are
And nothing else matters
- Metallica

Learn about the advantages of std::vector.

  • #25
    Join Date
    Aug 2002
    Location
    Madrid
    Posts
    4,588
    Dimitry, once the initial rules have been finalized, I'll place them in a sticky thread, same with the initial version of server and clients.
    Move forward and attack are the same thing
    Seems fair enough to me.

    ..and the direction the other creature is facing
    Sure, I forgot about that

    off-bounds (== outside the arena)
    occluded
    empty cell
    wall cell
    food cell
    another creature
    Right, I was thinking that we could have a wall all around the world or maybe even make it 'round' so that if you go past the north border, you end up on the south border (not for the initial version though).
    "Occluded" is of course a possible response from the server for some cell contents.
    Get this small utility to do basic syntax highlighting in vBulletin forums (like Codeguru) easily.
    Supports C++ and VB out of the box, but can be configured for other languages.

  • #26
    Join Date
    Sep 2002
    Posts
    1,747

    some more clarifications needed

    I haven't had a chance to look through the server coder yet to see if these questions might be answered there, but I was organizing some notes on a creature I've been considering and have a small little list of things I am still a bit unclear about. I thought maybe it might be good to post them, in case others needed the info as well.
    • I have seen mention of the move as 1 space forward and as a move being possible in any of the 8 directions. Which is the actual rule right now? This is basically asking if orientation is tied to movement, or if they can vary independantly (and if we may move only forward, this takes out direct diagonal moves).
    • Is the only action that consumes food right now the attack? I can't seem to find any rules for the food consumption of the other moves, but I do see a separation of a theoretical consumption for attack and a general modifier that applies accross the board.
    • Is there a life max beyond which you cannot regenerate (probably your starting amount, I would guess), or does regeneration occur with out capping? There is mention of life percentage (in regards to enemy stats visible) which does indicate a special reference value, but I could imagine percentages over 100 as well.

    Those are the major confusions I have right now. I'm sorry if these are answered somewhere I have overlooked, but any assistance will be greatly appreciated!
    */*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/

    "It's hard to believe in something you don't understand." -- the sidhi X-files episode

    galathaea: prankster, fablist, magician, liar

  • #27
    Join Date
    Oct 2001
    Location
    Dublin, Eire
    Posts
    880
    I think every single turn should require food consuption. Even staying idle should require some food consuption (maybe just 1, the minimum). One creature doing nothing still require energy just to stay alive. This will also force creature no to stay idle for too long.

    It could be something aroung the following ratio:
    Staying idle -> 1
    Scanning -> 2
    Turning of 90 (270) degrees -> 4
    Turning of 180 degrees -> 6
    Moving forward -> 6
    Moving diagonal -> 9 (if diagonal moves are used)
    Harvesting food -> 8 (of course it will bring more, but you need at least 8 to begin harvesting, otherwise, ... you are as good as dead).
    Attacking -> Depends on the attack capacity, ... Say the formula given by Yves M (I think).

    This is just a ratio that may be doubled or changed to find the best possible balance.

    I agree that the issue with the moves must be clarified. But may be it would be simple in the first stage to make only forward move with no diagonals.
    Elrond
    A chess genius is a human being who focuses vast, little-understood mental gifts and labors on an ultimately trivial human enterprise.
    -- George Steiner

  • #28
    Join Date
    Sep 2002
    Location
    Philadelphia ***Epoch: Timeless***
    Posts
    560
    I may be a little late in saying this, having not seen this project until now.

    In any environment with many characters, such as this, there is bound to be some level of diplomacy. Whether two units decide to share vision, or protect each other, or ambush another unit, or if a unit robs another unit of its food in exchange for sparing its life, etc., there will always be something. It would be a mistake not to include some sort of communication method between units. Perhaps not in the original version, but if possible it should be incorporated.

    At any rate, there would have to be some defining communication technique that would say who you can talk with (i.e. would it have to be someone in your sight range? would it have to be someone who isn't necessarily in your sight range but that you've met before?), when you can talk with them, what you can talk about (a limited set of keywords so that any unit can be programmed to understand them), how units send messages and respond to them, etc.

    I think it would add depth to the game and make it more "realistic". It could be simple, the conversation could initially consist of a few keywords, and each unit could send one message per turn and respond to one message before deciding on its action for that turn.

    If this sounds like a horrible idea, sorry! I think that if this isn't added, people would try to take alliances out of the game, and program it into their units for an advantage. Just an idea .
    SolarFlare

    Those who cling to life die and those who defy death live. -Sun Tzu

    cout << endl;
    return 0;
    }

  • #29
    Join Date
    Jan 2002
    Location
    Halifax, NS, Canada
    Posts
    985
    I beleve communication between 2 creatures would be for a version 2 or 3. I think it might be a good idea, but I think that it would be a lot of work for the first version, or even second. Of Cource they wouldn't communicate directly, but through the server.

  • #30
    Join Date
    Sep 2002
    Location
    Philadelphia ***Epoch: Timeless***
    Posts
    560
    As I've read through this, I have realized that there is a critical flaw in the movement of units.

    To begin with, these units will be smart; and all I mean by that is that they will know whether or not they should engage in battle with another particular unit based on the formulae of the outcome. If a unit is near enough to attack them, the about-to-be-attacked unit (which wishes not to be attacked) can avoid the attack by continually moving forward! The only way for the attack to work is if the runner runs out of food or if he runs right into an obstacle.

    It would not be very useful for a unit to be running after another unit for several turns merely to attack it. The attacker must have some sort of "attacker's advantage" to prevent this. For example, allow attacks to be diagonal, or allow units "in pursuit" to travel two squares while units "not in pursuit" travel only one.

    I do not wish to further complicate the initial version of the game, but unless I'm missing something (please point it out if I am!), the attacks will be a great disappointment.
    SolarFlare

    Those who cling to life die and those who defy death live. -Sun Tzu

    cout << endl;
    return 0;
    }

  • Page 2 of 4 FirstFirst 1234 LastLast

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •  





    Click Here to Expand Forum to Full Width

    Featured