I think etrigan can't prove what he's saying. You're absolutely right, Ekted. Continuum will never be "open-source" due to security reasons... OK. The real problem is that the code at execution time is always "open-exe", so the code can always be cracked/reversed and that obscurity that you mentioned disappear. You can always get an asm source of any x86 machine code. Even if the code is encrypted or whatever security techniques are applied you can still use a system level debugger like SoftICE to trap the code as it is executed. In the case of Continuum, SoftICE protection (just running or breakpointing) must be cracked before by using a diss!@#$%^&*embler and a hex editor/cracking program. We can discuss this issue for years and years, while all new modifications and security features got cracked systematically. I think the security should reside in the logic of the game protocol. The game should be played at server side mostly. The game is played a lot at client. All the client side features are more susceptible of cheating. I will use greens as an example. Greens are placed by the client on screen, so the server has no control at all of greens earned by players. Using the actual philosophy the game server will never be able to detect client cheats based on greens. If the client says it has gained an item by greening, the server has no way to validate it. Note that some greens are distributed by server to other clients (killing greens) but the green that your own client places randomly on screen when other green has expired is not distributed the same way. As a side result of this, you can have greens on your map that other players does not have on their maps. Also, the possibility of green based cheats is open. The server must accept every item you use because it has no mean to validate how you earned it. Why cheat with greens having the ?buy feature? Most people will use ?buy instead of cheating, but greening a brick, etc on the run (out of safe) could save your life many times. Setting the server to show ship state to spectators could help. But many zones won't do it because everybody will see smods/sysops cheating (abusing the *prize command). It is not the matter, but I also want to say that this game is designed for staff to abuse powers (not very nice). My point is on how the logic of the game protocol is open to client cheats. On the other hand, play the whole game at server side will introduce lag in some routines that are triggered locally at the client by now. This way, the client performance will be affected by lag. More game traffic will be introduced. It is just an idea that I present here: client performance against game security. I know it is crazy to pretend to play the whole game at server side, but some things must be done this way or there will always be security concerns with some aspects of the game. You can forget about people developing bots... this will always happen (even with a double key encryption system). Bots can be a lot of more stronger than the client could be by taking advantage of server features and bugs/holes and also by automating commands. Once again, playing the game at server side will reduce the power of clients/bots. Coconut emulator
