How do I approach this? Specifically, I know how I would approach this in javascript, but I don't want my images to be moved around and fixed through html/js manipulation.
Thanks,
CE
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Making a java standalone multiplayer application(non browser based)
Any time you write an application that runs on someones computer, that user has the ability to manipulate it however they want; It's their computer.
Though there's some ways you help combat this, having as many things as you can be server-sided is a good approach. This means that all data is stored on the server, and the clients only get to make requests to have data be changed. The server then gets the overall say in whether or not those changes are accepted. As a general rule of thumb, you should not blindly accept any data the client sends the server out-right, it needs to be checked for validity first on the server.
Though this wont stop people from making their client, for example, change player positions locally. That's not something you can really stop without an additional client-side anticheat system, but there aren't tools for this with Java, as far as I'm aware. It's higher level, and the JVM that houses your bytecode can always be changed by some exploiter.
What server-sided cheat prevention does, is it prevents users who are already exploiting have their exploits affect other users.
Certain game types are easier to protect than others. A lot of RTS's have an easy time with cheat prevention, because you can easily make the clients wait 100% on server synchronization (clients just send click requests to the server, server handles literally everything except drawing graphics). This creates a delay in input, which is not optimal for other game-types (see FPS's). First person shooters cannot have this type of synchronization, because the user needs instant feedback of what they're doing or the experience is ruined.
First, pick a GUI toolkit for Java. Swing, or the Eclipse SWT, are popular choices. (You could also pick a game engine with a GUI built-in, if you want to animate in real time or do 3D rendering.)
Second, pick a networking technology. It may be as simple as Java object serialization across a java.net.Socket, or as advanced as some custom protocol on top of a message broker like MQTT with very sparse byte-conscious serialization over a TLS connection, to something game-based based on small UDP datagrams.
Third, build your client application to make the appropriate requests on top of the protocol, render the result to the GUI toolkit, and collect user input to send new requests to the server.
Fourth, develop the actual server to receive requests, process them, and send the appropriate response messages.
There's the separate question of "what do I put into my messages" which depends entirely on what your application needs to do, what level of authorization you need, and so forth.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
