Non-public classes in CBot

[krzys-h]

For some use cases it might be nice to have non-public classes in CBot. That would prevent naming conflicts between programs (or multiple instances of the same program).

[immibis]

I would like to see public classes not exist actually, it makes no logical sense for multiple robots to share their RAM.

However that would break stuff from the original game.

[cbot-coder]

Public classes have a use: to share info between bots

[immibis]

@cbot-coder I don't care. It makes no logical sense for different robots to share their RAM.

[melex750]

It makes no logical sense for different robots to share their RAM.

By that logic, public functions also don't make sense.
It's a moot point since the game doesn't simulate RAM or a CPU.

In fact, there are distributed computing systems that operate as though physically
separate computers do share RAM with support from the OS and network.

I think the game wasn't even meant to be a literal simulation of robots.
It's a metaphorical representation of a programming environment, intended
for learning/teaching programming, where bugs(giant insects) are the enemy.
I actually read one of the original dev blogs that basically said as much.

[immibis]

It makes no logical sense for different robots to share their RAM.

By that logic, public functions also don't make sense.

correct

It's a moot point since the game doesn't simulate RAM or a CPU.

The game simulates separate robots, and you can easily see by looking at the game graphics, that there are no wires going between the robots.

You could say there is wireless communication, but there isn't, because we know what wireless communication looks like in this game (look at the ExchangePost send/receive animation) and there isn't that either.

[cbot-coder]

Feel free to design your solutions so as not to use sharing of data between bots. I typically don't use shared data, as I haven't found it to be terribly reliable or helpful in the missions I've programmed so far at least. Instead I typically give each bot a role to do, and certain parameters (such as, wheeled bot only goes for resources within 50 meters of space ship, winged grabber does things further away). I also tried having bots that need their cells replaced by a grabber, tell the grabber so via public data structures. But again, I found it not to work that well (for various reasons) and decided rather to have the grabber periodically look for bots that are standing still and have a near-empty cell. That seemed to be a bit more reliable. As for being semantically correct, I think it's really picking at minor details. If someone wants to, they could find all kinds of unrealistic things about the game and the programming. For example, the fact that bots have an almost God-like knowledge by using radar() to precisely pinpoint everything in the game and read their properties (unless it's magically hidden for the purpose of the level). In a more realistic world, robots would have to rely on and interpret sensory data just like we do: camera images, real radar or lidar (which can't see around corners), and so on. But that would be too hard for the level of programming this game is intended to foster, and might make it almost unprogrammable even for someone like me who has been coding for 30+ years.

…

On Sun, Dec 20, 2020 at 8:52 AM immibis ***@***.***> wrote: It makes no logical sense for different robots to share their RAM. By that logic, public functions also don't make sense. correct It's a moot point since the game doesn't simulate RAM or a CPU. The game simulates separate robots, and you can easily see by looking at the game graphics, that there are no wires going between the robots. You could say there is wireless communication, but there isn't, because we know what wireless communication looks like in this game (look at the ExchangePost send/receive animation) and there isn't that either. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#697 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASDSBLTJQS5JB2WJVUMLRZLSVX6TPANCNFSM4BXNL5IA> .

[melex750]

The game simulates separate robots, and you can easily see by looking at the game graphics, that there are no wires going between the robots.
You could say there is wireless communication, but there isn't, because we know what wireless communication looks like in this game (look at the ExchangePost send/receive animation) and there isn't that either.

ExchangePosts could be described as obsolete tech after the 'First Expedition'.
It's pretty obvious there is wireless communication when Houston sends messages to SatCom and programs to robots.
BotFactory gets data from ResearchCenter and AutoLab and sends programs to bots without wires or send/receive animation.