The purpose of visibility?



  • Just wondering: has there been an explanation of the purpose of visibility?  In a game that's all about automation, it seems a little strange that I have access to information that my code doesn't, especially since there are ways to circumvent it anyway. Do people feel that the game benefits from restricting visibility?


  • Culture

    I think the visibility thing is pretty good, and removing it would cause serious issues for a lot of players (looping over Game.rooms would be a nightmare).

    However, I do think there is a lot of information available to players that should be available to the AI. As it stands right now people who are playing the "automation" game are at a disadvantage because manual players can see-

    * Player GCL (allowing them to make decisions on who to attack)

    * Player rooms (allowing them to identify targets)

    * Portal Destinations (allowing them to pathfind)

    The player rooms and portal destinations can be overcome with scouting or by scraping the website to build a json database, but this is definitely an area where manual players have an advantage. I would like to see these functions added-

    `Game.map.getPortalDestination(roomname)` - returns a roomname or false.

    `Game.map.getRoomLevel(roomname)` - returns 0-8 (reserved through RCL8) or false.

    `Game.map.getRoomsByOwner(username)` - returns a list of claimed or reserved rooms.

    `Game.players.getGCL(username)` - returns the GCL of the player.

     



  • Or they could make Visibility a thing for manual players as well, hiding rooms from a player's view if they do not have visibility. Starting out visibility is a bit confusing, mainly due to the fact that you as a player can see it, why can't your AI?



  • tedivm: Depending on how visibility is removed, it's possible for it to not affect anyone's code. Game.rooms could continue to only return the rooms that you have creeps in, but Game.getObjectByID could be made to return the object no matter what, and a Game.getRoomByName could be added to return the Room object for any room on the map. Then, you could get all the room's attributes you were talking about.



  • I believe that would also have serious implications in the server-side code. Right now, all objects available to the user at all are created beforehand, and used to populate an internal "register" as well as all the find caches / Game.structures / Game.spawns / etc. Game.getObjectById is literally a function `return _register[id];`.

     

    If _all game objects_ were made available, this architecture would definitely have to change - creating one copy of every single game object per user per tick would be, well, very expensive. What the replacement would be, I don't know, but it would probably incur some additional performance costs, both with Game.getObjectById and other functions which use the internal register to validate things.

     

    The solution I would favor would be something like Game.inspectPlayer(player) to get GCL and a list of rooms with RCLs next tick, usable once per tick, as well as a Game.inspectRoom(room) function giving RCL, controller sign, owner, and a 50x50 grid of enemy/road/wall/empty squares (similar to the view on the world map). inspectRoom would also be usable once per tick, and would give results the next tick.