Jump to content

FeXoR

WFG Retired
  • Posts

    1.426
  • Joined

  • Last visited

  • Days Won

    28

Posts posted by FeXoR

  1. I just started to work on this again (other priorities in the last months).

    My main concern is the texture blending ATM.

    post-14196-0-08822200-1394304219_thumb.j

    I fear there is no way to make randomly distributed tiles of two or more types in the same area look well (just by blending). So I might implement a function to take care of removing single (or 3 or more connected tiles) tiles surrounded by others (Seams like I ran into a percolation like problem). That is most promising I guess.

    The reference of yours is a good one though I doubt we would use all of that because some of those functions are really slow and need to be applied multiple times (especially erosion).

    If you are interested in erosion you could try to check out my (many, never really working) approaches here: http://www.wildfiregames.com/forum/index.php?showtopic=16233&page=5#entry274289

    I intend to make a lib from all of this but I'm not qute sure which functions are worth to add there. Feel free to use them as you see fit. If you need a specific function and can't figure it out I'm willing to help.

    I'm likely to finish this map (realistic terrain demo) within the free period (but you never know what gets in the way ^^).

  2. Concerning game settings / ready:

    I think the game settings should be set before the game is actually hosted so they can't be changed afterwards.

    When you choose a game to enter you should see the game settings. Entering the game then counts as "ready".

    It's annoying how many PPL enter games before being ready to play and all other players then have to wait for them.

    This is the case in many new games and it's a bad idea IMO.

    • Like 2
  3. Thats a good example that "game improvements" should be playtested before being added.

    Formations is another example. Though units far away from each other don't try to reach each other any more in many situations the "center of mass" of the selected units move in the opposite direction of the target making chasing enemies a pain. On other occasions the stuck in a bunch of trees or other obstacles.

    So I ask again to add a default "simple" behavior to such features (making them optional) as long as it doesn't work well.

    So please add a "no-formation" formation giving the order to each unit individually and the ship (or other unit) to garrison troops in not change it's orders when units are ordered to garrison in it (while the experimental behavior could be optional).

    Adding things like this prematurely and non-optional makes the game worse and not better.

    • Like 1
  4. Go to the Terrain tab, and check what's under Misc tools ;):) In other words, there already is a resize map tool. It only uses the default sizes, so it might not be perfect for what you describe however, and it's a very generic size changing function, so you have no control over it really.

    Oh, yes, didn't expect it there.

    Are entities/actors remove from the unplayable map parts?

    "Resize map" should definitely be extended to allow manual input (as well as default sizes), and then also choose the "origin point" for the resize. Right now, it is the bottom left corner, which is not good for all cases, so it should be possible to be able to choose any corner or 'center' as an option.

    I agree.

    Some things nice to have would be:

    - Eventually remove "border fog" to see if entities are there (If happening in any case)

    - Choose map shape when resizing

    - Choose center of the resized map (Should be the center of the old map by default IMO)

    - Enable to choose a generic (square ATM since some functions assume (bad) that the map is square AFAIK) new map size (AFAIK no problems with that?).

  5. wraitii:

    Maybe, just maybe, the reason for no other AI development takes place is because the "API" does not support AIs in general but more Aegis or at least an AI designed quite like Aegis. About 100 lines of code are needed to use the API for a bot that does not throw errors and otherwise does... nothing.

    This hardly seams like an API to me at all...

    I didn't playtest the actual Aegis (since I had some time again there where the serialization issues) but I believe it's quite good so that's not my point. It's only about the API that is hard to understand and inflexible AFAIK.

    I'm still interested in designing a different AI and really think more then one AI is a good idea.

    AI tournaments (even with only Aegis around) could be used for balance testing (if Aegis can be easily configured so different types of units are used).

  6. @Lion.Kanzen:

    If you mean you want to get a square map from a circular (finished) map that only includes "designed" terrain (so it's smaller, 1 / 2^0.5 the size):

    ATM there's no way to do this because maps size can't be changed (at least not in Atlas).

    I don't think that would be a very helping feature though.

    A "reduce map size" function could help though that opens a size selection and then show a square of this size to be dragged to the part of the map wanted. Confirming would then reload the map containing only that area.

    Only supporting the default map sizes would lead to a lot of space lost, though (because the map width would decrease to 1/2 and not only to 0.707...).

    Still not sure if worth the effort of implementing it.

  7. Open the link (klick on the picture) -> you sould get to flickr

    Rightklick the picture -> a selection should appear

    Choose original -> the webpage should change

    Rightklick the picture -> a selection should appear

    Choose save image as (dependent on your browser)

    (At least this works for me on Opera)

    • Like 1
  8. Does units walking into the subdivision count as well (so the error may not always occur but only if units are tightly packed there by a player)?

    (This would be horrifying since the map will load but if a player commands his army through a subdivisions already containing entities close to the limit the error will be risen)

    On the other hand I don't think map designers shouldn't pack non-moving entities tighter than 1 per terrain tile (though actors might be).

    (However, the engine should not break because of this.)

    Performance is a valid reason to limit flexibility though sad IMO.

    (I think this should have been considered in the very basic design of the engine IMO but I think it's to late for that (?))

    I don't like unneeded hard limits in general though (I like flexibility) but I have not enough information to really get involved into this.

  9. I like it.

    I'm not so sure about the playability but I think you know of this yourself.

    Something similar could be used to place roads in a city map (I have thought about making wall_builder.js capable of adding branches for this purpose but maybe that's not the best idea in the first place).

    • Like 2
  10. hollth:

    It more Mythos_Ruler's idea with my thoughts added.

    Concerning the work:

    - The "wall connector" has to be modeled for every wall style (nut sure how much work)

    - The code needed to replace the entity should be very similar to the "wall to gate" upgrade (simple)

    - In wall placement methods the wall tower would have to be replaced with the "wall connector" (trivial)

    So I can't see any real problems here.

    It would be nice to have an upgrade animations, though (instead of instant entity replacement).

  11. Got an AI related error as well:

    Version: SVN 14696

    Map type: Scirmish

    Map: Alpine Valleys

    AI: Aegis (easy)

    Civs: Macedonian(Player), Random(AI)

    Settings: Otherwise default settings

    Cache: Cleared before starting the game

    Local modifications: None

    Error:

    ERROR: JavaScript error: simulation/ai/common-api/resources.js line 48 TypeError: that is undefined ((void 0))@simulation/ai/common-api/resources.js:48 ()@simulation/ai/aegis/queueplan--.js:47 ([object Object])@simulation/ai/aegis/queue.js:52 ([object Object])@simulation/ai/aegis/queue-manager.js:364 ([object Object])@simulation/ai/aegis/aegis.js:184 ([object Object],2,[object Object])@simulation/ai/common-api/baseAI.js:81  

    commands.txt

    system_info.txt

    mainlog.html

    interestinglog.html

    • Like 1
  12. I think even in visible areas some things might be better hidden.

    An enemy territory border e.g. enables you to walk around his territory without the risk of being attacked by a tower.

    IMO only those parts of an enemy players territory should be shown if it restricts your or an allies territory to be expanded.

  13. That's mainly because of the total number of polygons. When you just replace a texture, it doesn't make any difference. The polygon was going to be rendered anyway.

    Next to that, we also do quite a lot on the CPU. Like calculating the position of every entity before rendering, distance-sorting some of the entities, calculating the prop positions ...

    So textures don't generate any lag GPU wise and all lags (like e.g. cased by many entities) is CPU related?

    Well, then I'm out of arguments ;)

    (Still don't like explicit cruelty... but war games. I must have a twisted mind ^^)

×
×
  • Create New...