ETNA 2.1 - ETNA used for 3D?
Blitz3D Forums/Blitz3D Programming/ETNA 2.1 - ETNA used for 3D?
| ||
| Hi all. Is it possible to use ETNA 2.1 to send and receive 3D object data to and from a server, so you can see another player moving across the landscape? If so, can someone please link, and / or post a small example of this working? :) Thank you so kindly! :) |
| ||
| It would be massively inefficent to use a web-based database for a continuous stream of data, i'd think... Highscore tables don't need to be low latancy and continuously updating, keepung track of player positions and status is MUCH more involved... |
| ||
| I see. However, I want to encrypt ALL traffic being sent via TCP & UDP |
| ||
| If I'm reading this right, you wan't to encrypt the 3D coords of players? 1> erm why? 2> do MMO's and CoD type FPSers do this? it seems like an unnecessary overhead. Encrypting maps I can understand, player data, anything that can be modified by haxors to gain an unfair advantage, but real time frequent updates of numerous players, by the time you have encrypted, sent, recieved and then decrypted the co ordinates, chances are they have long since moved from that position and just increases lag. |
| ||
| How to do networking like a pro: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization https://developer.valvesoftware.com/wiki/Physics_Entities_on_Server_&_Client Always learn from the best! (i.e. if it's good enough for CounterStrike...) There's a lot of material there. Make sure to read it all, as it's all good stuff. |
| ||
| I only want to encrypt the MD5 transfer OF the packet itself. |
| ||
| MD5 is: 1) not a transfer 2) a hash, not an encryption (i.e. you cannot get the original data back out of it, it only generates unique codes from the data) 3) cryptographically worthless (in those contexts where a hash would be useful, MD5 is not secure anyway to anyone actually interested in breaking it) |
| ||
| Ok, so how would YOU go about it? |
| ||
| I guess what we really need to know is what you want to encrypt and why. That way we can acertain if it is a reasonable task to undertake. If the answer is "I don't want people to see the data!" well most gamers just game, too busy running and gunning to worry about a constantly changing stream of hexadecimal numbers. This would be all the players positions constantly changing. The level data files, unless stored localy from instal, yes I can see a need or want to encrpt these from prying eyes, but whilst gaming a gamer is not going to worry about such things. Out of game and in subfolder however ... So if the level is downloaded to a temp file, it being encrypted and due for deletion after close of session offers players less of a chance to open it up in a custom world editor (would they go to the trouble of coding one?). Also you would recomend reading up on public/private key. |
| ||
| What kind of key do you speak of? Also, the temp file is a VERY good idea.. HOWEVER... I dont WANT them editing my content... That is ILLEGAL. |
| ||
| I don't know how 'illegal' it is world wide, I'd hazard a guess as not in the slightest, modding and reskinning rely on modifying existing content. If for example someone modified a wall texture to include rude graphiti or swap it out for a wall sized image of porn, that would only appear on their screen and not the server for all to see taking a texture and palming it off as your own work, yeah thats not in the good side of the scale, reskinning CoD into MLP:FiM, now thats just awesome. public/private key encryption, I'm sure wiki has an indepth article on it edit: I'm not sure about pak/zip files, but I'm sure you can password lock them so nothing of use can be opened without the password. Then all you need to do is enter the password via code, making sure the password in the exe is either encrypted itself, or just obfusticated (sp) enough to not be known to casual prying eyes. Last edited 2012 |
| ||
| I dont WANT them editing my content... That is ILLEGAL. No, it's not. I'm pretty sure you've been over this before, and the answer now is the same as it was then: you can't stop people accessing files on their own machines. Even trying to do so is immoral (and may actually be the illegal one of the two, depending on how you go about it. I remember your proposal last year to delete files not authorised by your program: this would quickly get your game classified as a virus and banned from every portal). This is something that seems to come up a lot on the forums. The answer is: get over it. It doesn't affect you or the other players or in fact anyone if someone decides to get into the game resources and change their gameplay experience. In the highly unlikely even that they attempt to resell your content without a licence, you are protected by copyright, which is the only form of protection that matters. Adding mechanical encryption wastes your design time, their CPU time, massively lowers the game's perceived value (it comes from a control-freak who doesn't believe in letting customers actually use their own stuff? Nah, I'll pass), especially if you don't include modding tools, and contributes absolutely nothing to the important areas of playability, performance, and good design. Last edited 2012 |
| ||
| It's not illegal or immoral. At least in the US (yeah, yeah, yadda yadda free speech yadda yadda). Not saying I agree or disagree that it should be either. |
| ||
| I'm sure it is illegal to distribute an application that deletes files from your hard disc, that it didn't create, without the users permission. I'm surprised that's not the case in the states :) |
| ||
| If its YOUR files specifically for YOUR game, it IS illegal |
| ||
| If its YOUR files specifically for YOUR game, it IS illegal No, it's not. See above. Repeat as necessary. Yes, I am aware you live in a different country. Doesn't make a difference in this case. And even if you did care about such a pathetically trivial issue, your primary protection is through copyright law, as I said above: physical encryption contributes absolutely nothing. (Believe it or not, you can't just make up laws to match what you want. Especially since there is, as outlined above, no reason to want this because all it does is inconvenience you and others.) Last edited 2012 |
| ||
| Hey. I will block my files from access if I want to.. That's no one else's business.. ANYway... Can someone explain a way I CAN encrypt the data? :) |
| ||
| The point is, Rez, the files of the game installed on a user's machine belong to the user, they are essentially just bits of electronic data read from THEIR hard-drive and decoded by THEIR CPU and OS then displayed on THEIR monitor. They can add to, modify, delete or rename that data how they see fit at their leisure in total and complete legitimacy. They may have signed/agreed some form of licensing agreement, if you include such a detail in distributing the product, but this too, can only at most ensure that there is a contractual agreement for them to, say, "not try to modify the files for purposes that will interfer with the normal running of the game" or "circumvent or otherwise affect the code or network transmissions in order to gain an unfair advantage" etc.etc. The legality concerning such agreements is another matter entirely. Back to the original topic: It sounds like what you're after is something to ensure that: a) people dont cheat by modifying the executable code/media/libraries b) people dont cheat by altering or fraudulently sendingor otherwise affecting the data sent to/from peer clients or servers via network c) people dont decompile/crack or otherwise examine your code in order to make cheats, steal some IP relating to some procedure or process, or gain some knowledge of the games working that may allow them to gain an unfair advantage. Unfortunately, this is all IMPOSSIBLE to prevent completely. Even the most comprehensive systems designed and envisioned by experts can be and ultimately will be circumvented, hacked themselves or otherwise 'beaten' by the unscrupulous and technically poroficient. The reasons why? 1) Games require data to be stored, processed and handled on a private person's client machine. 2) Networked games require information to be sent from Peer-to-Peer or Server/Client. 3) Any processing, storing or transferance of information can be halted, examined, prevented, duplicated or falsified 4) There is money to be made in the ability to crack, hack, decipher, decode, decompile, reproduce, forge or otherwise find a method of cheating in products. 5) Any system working against cheats and cheaters must be maintained regularly. Every time a cheat/hack appears in the wild, the system must be updated to counter the threat. When this happens, the 'hackers' then work on their own update, allowing their cheat to circumvent the new level of protection. It's an endless cat & mouse game, where the system is always having to catch-up. 6) Decompilers, Memory-readers, dissassemblers etc. are all very easily available as well as other, perfectly legitimate tools which can be abused for less ethical purposes. Typically, the methods employed by mainstream commercial bodies at tackling aspects of cheating and unwanted modification are: 1) Customised file formats for media and 'packing of data' Such specialised files will take longer to read/write, and wont be natively read by Blitz, so you'd need to have a good understanding of the data structure and how to implement it for each filetype. 2) As mentioned above, temporary unpacking, reading, then deletion. 3) File contingency checking, for example, MD5 checks etc. Version checks, Modified Date checks 4) Only send coded packets, specify certain requirements prefixing and suffixing packets etc. 5) Transmit instructions not details via the network. If those instructions are in a coded format, it will be much harder for people to determine what's being transmitted. Things like coordinates are kinda obvious to someone who knows what they're looking for. 6) Limit client-side content where possible. Depending on the infrastructure of the game networking model, try to keep most information server-side only. For example, why download the entire map to the player, permanently if all they need is the info for where they can walk. 7) Where possible, check for 'impossible' scenarios in-game that suggest (without any doubt) player must have cheated. For example, being in inaccessible areas. 8 ) Ensure some form of Administrative oversight to servers or for P2P gaming, perhaps some form of voting. It wont protect your code so much, but at least will make players feel more secure and give them the ability to deal with cheaters runing their experience. ____________________________________________________________________ Lastly, I dont know the stage you are at with your game, but considerations such as these are best left to the end of development, once your game is pretty much complete - otherwise, it can and most probably will be harder for you to make changes and debug what you're working on. |
| ||
| Im gonna check for every SINGLE thing that could POSSIBLY go wrong when the cheater uses a cheat. for example... If they are WAY too high in the air, then i'll know they have a fly cheat on, or if THAT doesnt stop them, then UNLESS they are on a flying animal or machine of some kind, or hitting the jump button, then it will do a check to ensure they are on the ground. if they arent, and arent jumping, or are WAY too high, i'll be able to tell if they cheated, and ban them from the game entirely :) |
| ||
| Try to keep your checks efficient, if the code's too busy checking, it wont be fun because it's so laggy etc. Also, remember that if someone can hack your code to make their character fly, they could possibly hack your game to prevent it checking for the cheat - the more you try to prevent cheating, the more cheaters will find ways around it... once you start on that route, you commit yourself to continually maintaining and updating to try and stay 'on-top' - but good luck with it :) |
| ||
| BWAHAHA! Let them try :) |
   |