Jump to content

agentx

Community Members
  • Posts

    276
  • Joined

  • Last visited

  • Days Won

    7

Posts posted by agentx

  1. > Do you know an option for the AI to store informations or writing/editing files?

    There is none. Except another debugging tool reads and writes from stdout.

    > to remember past skirmish statistics. Even after shutdown the system.

    0AD is deterministic. Every game is replicable on every computer. That means bots in a multi player game need *same* code, data and thus behavior. If one bots learned something, he needs to share it with all other, too. Otherwise you'll get out of sync errors very quickly.

    > Or maybe there is another way to do this?

    Sure, spend the bots a XMLHttpRequest object like browsers do to sync over the net. Some projects link to curl to embed it. Then the bots can make sure having same knowledge.

    Or, very advanced, let players train their private ally bots, then the game has to sync the full bot code across all connected players.

    In both cases I'm ready to work on the server part, syncing data or code. Just the c++ part is way over my head, especially to make it work async with callbacks.

  2. I don't know how many people work on the common api. If I had to guess, I'd say less than a hand full and once you got the quirks right, a documentation is not needed. So, I'm more in favor of documenting the quirks properly by hand than an automated documentation, because it would help to design a new bot api.

    But even that is far less interesting than an advanced attack/defense system useable as a plugin for bots... :notworthy:

  3. One can run Object.keys(Engine).forEach(k => print(k + "\n")) within a bot and get the list of available commands:

    ProfileStartProfileStopPostCommandIncludeModuleDumpHeapForceGCDumpImage

    More is available via global, Object.keys(global).forEach(k => print(k + "\n")) :

    API3
    clone
    deepcopy
    DoesModificationApply
    Engine
    error
    g_pluralTranslations
    g_pluralTranslationsWithContext
    g_translations
    g_translationsWithContext
    GetIdentityClasses
    GetTechModifiedProperty
    GetVisibleIdentityClasses
    global
    HANNIBAL
    HANNIBAL_DEBUG
    isNonEmptyString
    log
    markForTranslation
    markForTranslationWithContext
    MatchesClassList
    PlayerID
    print
    sprintf
    translate
    translateMessageObject
    translateObjectKeys
    translatePlural
    translatePluralWithContext
    translateWithContext
    Vector2D
    Vector2Dprototype
    Vector3D
    Vector3Dprototype
    vsprintf
    warn

    Same thing (Engine) in the GUI compartment looks different:

    AddPlaylistItem
    AssignNetworkPlayer
    AtlasIsAvailable
    BuildDirEntList
    CameraFollow
    CameraFollowFPS
    CameraGetX
    CameraGetZ
    CameraMoveTo
    ClearAllPlayerReady
    ClearPlaylist
    ConfigDB_CreateValue
    ConfigDB_GetValue
    ConfigDB_Reload
    ConfigDB_SetFile
    ConfigDB_WriteFile
    ConnectXmppClient
    Console_GetVisibleEnabled
    Console_SetVisibleEnabled
    Crash
    DebugWarn
    DeleteSavedGame
    DisconnectNetworkGame
    DisconnectXmppClient
    DisplayErrorDialog
    DumpSimState
    DumpTerrainMipmap
    EnableTimeWarpRecording
    EncryptPassword
    EndGame
    Exit
    FileExists
    ForceGC
    FormatDecimalNumberIntoString
    FormatMillisecondsIntoDateString
    GameView_GetConstrainCameraEnabled
    GameView_GetCullingEnabled
    GameView_GetLockCullCameraEnabled
    GameView_SetConstrainCameraEnabled
    GameView_SetCullingEnabled
    GameView_SetLockCullCameraEnabled
    GetAIs
    GetAllLocales
    GetAvailableMods
    GetBoardList
    GetBuildTimestamp
    GetCurrentLocale
    GetDictionariesForLocale
    GetDictionaryLocale
    GetEngineInfo
    GetFPS
    GetFallbackToAvailableDictLocale
    GetFileMTime
    GetFileSize
    GetFollowedEntity
    GetGUIObjectByName
    GetGameList
    GetLocaleBaseName
    GetLocaleCountry
    GetLocaleLanguage
    GetLocaleScript
    GetMapSettings
    GetMatchID
    GetPlayerID
    GetPlayerList
    GetProfile
    GetProfilerState
    GetSavedGames
    GetSimRate
    GetSupportedLocaleBaseNames
    GetSupportedLocaleDisplayNames
    GetTerrainAtScreenPoint
    GetUserReportStatus
    GuiInterfaceCall
    HasXmppClient
    HotkeyIsPressed
    IsAtlasRunning
    IsPaused
    IsRankedGame
    IsUserReportEnabled
    LoadMapSettings
    LobbyBan
    LobbyGetNick
    LobbyGetPlayerPresence
    LobbyGetPlayerRole
    LobbyGetRoomSubject
    LobbyGuiPollMessage
    LobbyKick
    LobbySendMessage
    LobbySetNick
    LobbySetPlayerPresence
    MusicPlaying
    OpenURL
    PickEntitiesAtPoint
    PickFriendlyEntitiesInRect
    PickFriendlyEntitiesOnScreen
    PickSimilarFriendlyEntities
    PlayAmbientSound
    PlayMusic
    PlayUISound
    PollNetworkClient
    PopGuiPage
    PopGuiPageCB
    PostNetworkCommand
    ProfileStart
    ProfileStop
    PushGuiPage
    QuickLoad
    QuickSave
    ReadFile
    ReadFileLines
    ReevaluateCurrentLocaleAndReload
    Renderer_GetDisplayFrustumEnabled
    Renderer_GetGenTangentsEnabled
    Renderer_GetParticlesEnabled
    Renderer_GetPostprocEnabled
    Renderer_GetPreferGLSLEnabled
    Renderer_GetRenderPath
    Renderer_GetShadowPCFEnabled
    Renderer_GetShadowsEnabled
    Renderer_GetShowSkyEnabled
    Renderer_GetSilhouettesEnabled
    Renderer_GetSmoothLOSEnabled
    Renderer_GetWaterFancyEffectsEnabled
    Renderer_GetWaterRealDepthEnabled
    Renderer_GetWaterReflectionEnabled
    Renderer_GetWaterRefractionEnabled
    Renderer_GetWaterShadowsEnabled
    Renderer_GetWaterUglyEnabled
    Renderer_SetDisplayFrustumEnabled
    Renderer_SetGenTangentsEnabled
    Renderer_SetParticlesEnabled
    Renderer_SetPostprocEnabled
    Renderer_SetPreferGLSLEnabled
    Renderer_SetRenderPath
    Renderer_SetShadowPCFEnabled
    Renderer_SetShadowsEnabled
    Renderer_SetShowSkyEnabled
    Renderer_SetSilhouettesEnabled
    Renderer_SetSmoothLOSEnabled
    Renderer_SetWaterFancyEffectsEnabled
    Renderer_SetWaterRealDepthEnabled
    Renderer_SetWaterReflectionEnabled
    Renderer_SetWaterRefractionEnabled
    Renderer_SetWaterShadowsEnabled
    Renderer_SetWaterUglyEnabled
    RestartEngine
    RestartInAtlas
    RewindTimeWarp
    SaveGame
    SaveGamePrefix
    SaveLocale
    SendChangeStateGame
    SendGameReport
    SendGetBoardList
    SendGetGameList
    SendGetProfile
    SendGetRatingList
    SendNetworkChat
    SendNetworkReady
    SendRegisterGame
    SendUnregisterGame
    SetActionGain
    SetAmbientGain
    SetBoundingBoxDebugOverlay(true)
    SetCameraData
    SetCameraTarget
    SetCursor
    SetMasterGain
    SetMods
    SetMusicGain
    SetNetworkGameAttributes
    SetNetworkPlayerStatus
    SetPaused
    SetPlayerID
    SetRankedGame
    SetSimRate
    SetTurnLength
    SetUIGain
    SetUserReportEnabled
    StartGame
    StartMusic
    StartNetworkGame
    StartNetworkHost
    StartNetworkJoin
    StartPlaylist
    StartRegisterXmppClient
    StartSavedGame
    StartXTimer
    StartXmppClient
    StopMusic
    StopXTimer
    StopXmppClient
    SubmitUserReport
    SwitchGuiPage
    Translate
    TranslateArray
    TranslateLines
    TranslatePlural
    TranslatePluralWithContext
    TranslateWithContext
    UseLongStrings
    ValidateLocale

    What I miss the most is interactively firing methods a bot has during run time, like you do with the GUI console(F9). Once a bot runs, nothing can interfere. Access to the camera would also help with testing. Another trick would be to chat commands to the bot, but that doesn't work either.

  4. That would be quite a challenge. The graphics are composed finally at the graphics card after the shaders did their work. So X has to grab them from the GPU, convert into an internal format, send them over the network, convert them again on the other machine to display them. Assuming 60 frames per second * 1024 * 768 pixel * 3 colors, that will hit the fan on both machines. Without knowing any specs I think server B has far less to do with playing the game from its own hard disk. Decent graphics cards are needed in both scenarios anyway.

    But I'm curious, did you successfully test this with any other real time 3D game?

  5. Well, there are different types of reachability:

    Unit wants to go from land cell to another land cell, both not connected: No pathfinder needed, that's terrain analysis. The path can be blocked by water, mountains or other non-walkable cells. It helps to have a list of regions which are connected and the mean of transport (ship, feet).

    Unit wants to go from island beyond shore into water: pathfinder should stop at first or nearest dee water cell and no repeat.

    Unit wants to go from land cell to another land cell, obstructions can be non-movable (houses, etc), completely blocking the path or just some cells. If full blocking there is no need to run the pathfinder again as long as the house is still on the map. This can be solved by temporarily splitting a region into two and make the pathfinder listen to destroy events.

    Or there are other units blocking cells or the path. Here a time limit makes sense.

    I think the challenge is to tell the module asking the pathfinder, why the pathfinder failed and that module should be clever enough to not hammer the pathfinder with unsolvable requests. Basically a pathfinder response is success w/ path, partial success w/ partial path, permanently blocked by terrain, temporarily blocked by immobile obstruction or temporarily blocked by mobile obstacles with partial path if available.

    On top the size of a unit matters, elephants and sieges should not get lost in a forest.

    I'm not sure if temporarily blocked by wall should get a partial path or not. The player might want to destroy the blocker with his units or not. In case of an AI having it self locked out, I'm not sure too. But an AI should be clever enough to not build houses on the only way out of the village. Unfortunately that sounds more easy than it is. What should not happen are AIs randomly building structures on the map and destroying them because the pathfinder said so.

    What I have in mind for Hannibal is taking the CC, creating a circle around and from 10-16 points on that circle let the pathfinder compute a path to the cc. Then you have a list of cells from multiple paths. I think building houses on cells which appear multiple times in that list is not a good idea. The idea is to make "streets" an obstruction for buildings.

    • Like 2
  6. I've collected quite some papers about RTS bots. From time to time I'll present here either a recently published one or one otherwise interesting. Research on agents in RTS games is very active, because the time constraints and the broad range of needed AI technologies is challenging. Doesn't doing science by playing RTS games sounds like an acceptable job description?

    I'll start with the 100 page thesis BDI agents for Real Time Strategiy games It is about an 0AD bot written by Andrea Dallatana. Unfortunately he no longer works on the bot. He describes in detail the mechanics of his bot. One idea I especially like is the job market to avoid units standing around doing nothing. Here is the module structure of ABot:

    0adbot.png


    Currently discussed at HackerNews is A Survey of RTS Game AI Research and Competition in StarCraft (2013), 19 pages. The authors specifically analysed bot versus bot games and state: ... the top three ranked bots in the competition (Skynet, Aiur and UalbertaBot) do not change their strategy at all depending on their opponent. For example, the Skynet bot (both in 2011 and 2012), always uses the same opening (two gates), except when playing a Terran opponent, when it uses nony. This reflects the trend that the performance of bots is still more dependent on carefully handcrafted and non-adaptive behaviors, ...
    The paper includes and describes a long list of detected bot strategies. Might be interesting to some human 0AD players too.

    Very technical is Kiting in RTS Games Using Influence Maps. Kiting is a trick bots can do easier than humans, because the micro management is overwhelming. In short a unit does a ranged attack on another unit and flees out of the range of the attacked unit before it reacts.

    kiting.png

    I'm eager to implement this in Hannibal.

    Have fun reading!

    • Like 2
  7. I'm leaning towards more simplicity and more sandbox. "pop/eco/military/building/tech formula" sounds like a ton of forum posts about "balancing" this formula. I would just make phases a costly tech. Then it is up to player to decide how he accumulates this wealth of resources. If someone spends an hour to advance to phase town with 5 units, well, then he earned it and it is not even unrealistic. Also, I think, if players start optimizing their game play towards a formula it restricts the game and many features remain unrecognized or unused. Not to mention the frustrating hours a newcomer must spend to grasp a rather complex formula. 1000 food and 1000 wood is hard enough to gather.

    • Like 2
  8. Actually path finding should even not start if the target is unreachable as the result is always a very costly full map scan. I had another effect recently while playing a random game on Alpine Valleys against 2 AIs. My CC was in the middle so I isolated one AI completely with a wall. Framerate instantly dropped to 2 fps.

  9. Money has multiple functions: Something you can easily carry with you and enables exchange with anybody willing to sell his goods. That's covered in the game, the market doesn't care whether you deal with tons of metal or huge amounts of grain. Every deal needs the exact same time. It is like an economy driven by bitcoins. Also, if your storehouse burns down, you loose nothing, all resources are safe and secure in an invisible vault. and you can donate to other players, faster than wall street.

    What's missing is a bank, which takes interests for credits, threatens every client being late with payments and naturally earns the most during a war, e.g. the Iron Bank of Braavos. :ph34r:

    I see there is now a mix of 0AD warfare and 2100AD economic transactions. But I would not trade spending time with the beautiful 3D view for a spreadsheet like GUI to have more realism.

  10. > a massive speedboost

    While the blog is quite excellent, the boost is only about generator functions. They are tricky because they maintain state after exiting via yield. And there is no simple way to get this state out of a generator function to e.g. save it somewhere. And if you don't use yield, well, then normal functions do the same thing much faster.

    The other thing is while it is elegant and memory preserving to implement let's say a generator which provides a million Fibonacci numbers or primes you need another iterator function to get the iterator protocol running and the whole thing becomes really slow.

    So, you gain readable code and small memory footprint at the cost of speed...

  11. Thanks Yves, that's a deep investigation. Probably I miss something, so let me ask: The pie charts express a percentage, is this the time spend running or where the tracer got caught? If it is the latter a difference of ~6% re IonMonkey _might_ still indicate a pretty big overall difference, given the huge optimization potential of native versus baseline. Also, is it a game with bots or only simulation?

×
×
  • Create New...