Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (580)
games submitted by our members
Games in WIP (500)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3
1  Java Game APIs & Engines / Java 2D / Re: Vectorization of image in Java (triangles on top of image) on: 2009-07-21 00:05:55
Wow that was answered quickly. Thanks guys, lots of good information.

Although I'm not sure what bleb meant with "threshold distance"?

I think you mh114 meant that I should check if the direction from A towards B is the same as the direction from B towards C, then I can remove B. I think it's pretty math-heavy and requires stuff like Math.sin to be used, but it will work.

About your link thijs, I'm sure there could be lots of useful information on that site, however finding it seems to be a quest on its own. I will save the URL, but I wonder if it won't be faster to do a search on the net instead of looking at the source of that project when I want to find out an algorithm. Is there anything in particular you think is good or useful in the JTS Topology Suite?
2  Java Game APIs & Engines / Java 2D / Re: Vectorization of image in Java (triangles on top of image) on: 2009-07-20 01:36:42
Sorry for the late reply, haven't read for a while.

Thanks for your thoughts, the JOGL tesselator sounds great! Did a search and came up with a few links which I'll post now in case someone else needs them:
http://www.songho.ca/opengl/gl_tessellation.html
http://glprogramming.com/red/chapter11.html

Also found this which might be useful:
http://www.ecse.rpi.edu/Homepages/wrf/Research/Short_Notes/pnpoly.html
It's for finding if a point is inside a polygon, not exactly related to this thread maybe but I'll post it anyway since it may come in handy sometime.

Your suggestions are great. However I've been thinking that to solve the first "multiple image" issue maybe I can just remove the pixels of a found polygon from the original image before I look for another polygon?

Since you seem to know stuff I thought I'd ask if you also have a colution for removing unnecessary points from a polygon? Imagine this example:

1  
2  
3  
4  
5  
00100
01110
11111
01110
00100


This will generate four points too much, these points aren't needed since if they were removed the polygon would look the same. The polygon have four corners, would be nice to have four points then instead of eight. Do you have any suggestion as to how unnecessary points can be detected? To be clear I have marked the points that are not needed with "X" here:

1  
2  
3  
4  
5  
  1
 X X
1   1
 X X
  1


Thank you again!
3  Java Game APIs & Engines / Java 2D / Re: Vectorization of image in Java (triangles on top of image) on: 2009-07-08 03:46:07
You should lookup the marching squares algorithm:
http://en.wikipedia.org/wiki/Marching_squares

It does exactly what you want, and the wiki entry links to a Java implementation.

Hey thijs, thanks a lot for your reply! I'm glad this thread got one. Smiley That algorithm will be very useful, awesome that there already is a Java implementation of it too.

But it doesn't do exactly what I want. What I get from that algorithm is the path through a object's outline, from an origin and back to the origin. From this:

1  
2  
3  
4  
5  
6  
00000
00000
00110
00110
00010
00000


This would be returned: S, S, E, S, E, N, N, N, W, W.

That is the path around the ones representing the object in the code above. It can be parsed in order to take out the coordinates of every corner (every change in direction), and then the results of that can be parsed to remove unnecessary coordinates that follows the same direction (for diagonal lines). Then I would have the coordinates of the outlines of one object in the image.

However I figure this can't discover many objects in one image. And it also won't detect holes inside a object, like so for example:

1  
2  
3  
4  
5  
00000
01110
01010
01110
00000


And mainly, it won't divide the object into triangles (like in my example picture). That's the biggest problem. I guess some, if not all, of these things can be implemented somehow using the algorithm in some clever way, but I can't figure that out myself.

Edit: Forgot to close a code tag.
4  Game Development / Networking & Multiplayer / Re: DatagramPacket delivery system (UDP in Java) on: 2009-06-29 20:17:47
Thank you for your two cents delt0r. It was a good read.

I have been reading a lot of articles lately, about different network strategies etc. All articles I found have been using UDP, I've been thinking about trying to get JeNet working after all and go with UDP. But I'm still not sure what to do. Having big trouble in deciding how my game "architecture" should look. Making a network game sure isn't that easy, I need to find a structure I like and feel comfortable working with. I think I'll try and make a server using TCP next, but single threaded and non-blocking, and see how that feels. You are right in that the Internet doesn't have some of the problems it had before (I guess, sounds reasonable), and I hope TCP will work satisfactory. I read somewhere (I think it was a warning on one of Sun's UDP tutorial pages) that some facilities block UDP traffic, which means making the game using TCP will make it playable in more places.

Thanks again fellas.
5  Game Development / Networking & Multiplayer / Re: Preventing cheating in network games written in Java on: 2009-06-29 19:28:33
Oh sweet, had missed that. Didn't know he had myspace, only ever read his blog at http://mm.soldat.pl (and not so often).

Definitely about time he rewrote the net code for Soldat, though I could have sworn he said he wouldn't work on Soldat any more. Are you sure he isn't just rewriting the net code for his Link-Dead game? Found this: http://mm.soldat.pl/?p=368 It doesn't say exactly which game he is rewriting the network code for.
6  Java Game APIs & Engines / Java 2D / Vectorization of image in Java (triangles on top of image) on: 2009-06-22 20:31:44
Alright, time to kick it up a notch. I've been thinking lately:

Say you have a 2D game seen from the side and the map is build using polygons. So when you build the map you need to place each polygon manually.

Imagine if there was a way to automate this - instead of building a map you draw a picture of how you want the map to look and then let the application build the map for you by filling what you have drawn with triangles (polygons).

Here's a small example, the image drawn will be in black and white (black = air, white = ground). The yellow lines are the polygons that the application has calculated to fill the white space.



Here's how I would like the code to look:

1  
2  
3  
4  
VectorizationTool vt = new VectorizationTool(Color.WHITE);
ArrayList<Polygon> ground = vt.process(<image object>);
vt.setColor(Color.RED);
ArrayList<Polygon> lava = vt.process(<image object>);


There we have it, would be very simple to use. We create an instance of the tool where we say that the color white is the ground, then we process the image and get the polygons representing the ground in our map. All other colors that arent pure white will be ignored. Then we just switch which color to process and use the same image to get the polygons that should represent a "lava" type of ground. The "Polygon" object can simply be the polygon's three corners' X/Y coordinates measured in pixels. (0,0) would be at the top left corner of the image that is processed.

Now my question to you fellows is as follows: How would one go about implementing this thing? Is there already available source to look at, or maybe even something like this already exists in Java and is ready to use?

I've been searching the net for this a bit but come up short. There are many algorithms out there, but I'm not sure which one I want that does what I want it to do or which one that is most effective. Hopefully there are people on this forum that knows this better than I do, I'm not at all good at math so I bet there are plenty of people here that can advise me.

(In case this thread will become a success I will now write down some key words to help others to find this topic more easily by search in the future: trace bitmap to vector, Raster-to-Vector Algorithm, Vectorization, convert bitmap to polygons, convert image to polygons, image edges java, fill image with polygon java, polygon mask java, poly2mask java. Some of these "keywords" might make no sense but they are part of what I searched for in order to finally decide on the thread's subject.)
7  Game Development / Networking & Multiplayer / Re: DatagramPacket delivery system (UDP in Java) on: 2009-06-22 19:32:25
Honestly I'm not a big fan of the way that java.net is structured either, but almost everything for JGN is in the forum: http://forum.captiveimagination.com/

I'm the creator of JGN so I can tell you it's still supported, although the API is pretty stable and hasn't needed any changes for a while now.

Pleasure to meet you. Although I won't use JGN for now I'll keep that in mind, thanks. If the project is in fact still supported may I suggest you make some kind of update on https://javagamenetworking.dev.java.net/ so that the "archived due to no activity"-message will disappear?

Maybe you have something insightful to add to the debate concerning whether to bother to use UDP or not? I'm guessing there has been some work on reliable UDP transfers in JGN (haven't checked though).
8  Game Development / Networking & Multiplayer / Re: Preventing cheating in network games written in Java on: 2009-06-22 02:23:18
Soldat's my favourite game too - if you've ever been pwned by Spas-Tard!, that's me Smiley

Soldat's main network code failing is that in a concession to dealing with some aspects of lag, it appears to allow the client code to arbitrate what's happened, specifically, the way players move, not so much the bullets, I think. So things can explode on the client and send a player flying, but the server doesn't register the explosion at that location and so the player takes no damage, yet the client tells it that one of the players has accelerated massively. It's this that's behind the speedhacks, I think - the server allows clients to make decisions about movement. Mostly in the name of smooth gameplay - there's almost no warping in Soldat, ever, which is nice. But the server does do hit arbitration,  hence the famous "Soldat heart attack", where you suddenly and unexpectedly croak when a bullet not visible on your screen for whatever reason kills you.

Cas Smiley

(Screw what I said about staying on-topic in this thread!) Cheesy Ah, how nice meeting someone else that fancy Soldat as their favorite game, that's the first time that ever happened to me.

I just wish the guy that does Soldat now (since MM stopped working on it) would focus a little bit more on the network part of the game instead of stuff like a in-lobby IRC client-tab that nobody uses and exploading heads from 50% of all sniper headshots. There's lots to do, first of all there's the eat bug (aka "hit") where due to package loss your bullet never reaches the server so to speak (I have read Soldat uses UDP, he probably does nothing about lost packets). But the weirdest thing is still when you hit someone with a M79 grenade and they fly away by it (meaning it hit on their screen), but the guy doesn't die. So the server recieved the projectile and passes it to the other guy's client, where it hits, but it doesn't hit on the server. Then the guy reports to the server that he has recieved force and is being pushed in a direction, and the server accepts it even though he apparently is out-of-sync. Adding to that (which has been in Soldat forever) I think the network code somehow got worse in Soldat 1.5, so I stick with 1.4.2 still. I wonder if Soldat is beyond help concerning the network code. I really think they should have added something new and fresh in the latest version of Soldat, one new gun or even a new hat to wear would have been completely awesome. Instead we get exploading heads as the biggest new feature, something that I think happens way too often for it to be remotely cool (they should have made it so that it only occurred if the player was "overkilled" with a headshot, given at least negative 75 hp). Over one year between versions and we get exploading heads. =P I know there was that voice taunt thing too but I don't care about it, the voices wasn't that good and I always play with the game sound off and my music on.

But even with negative stuff taken into account Soldat's still a fun game. Smiley
9  Game Development / Networking & Multiplayer / Re: DatagramPacket delivery system (UDP in Java) on: 2009-06-22 02:00:09
You asked for UDP + reliable delivery + in order deliver + already written. That defines TCP. How could you possibly not expect to receive that reply?  Huh

Now I'm all for UDP when used correctly, but you basically seem to have read a bunch of (out of date) articles and the only point you've gone away with is that UDP is a magical silver bullet of network code.

If coding up a simple ack/resend over UDP feels like "out of your league" then you definetly be able to produce a better alternative than TCP. TCP may be conceptually simple but under the hood it's got a lot of flow control and heristics that make it very efficient. If you're not going to code those yourself you will get worst performance.

The trick to getting good networking performance with UDP is to write your protocol with UDP's limiations in mind. That often means something like the quake 3 networking model where you're simply blatting out the latest game state for the contantly updating stuff (object positions/velocities) and a separate TCP stream for essential events (object spawn, player killed, game finished etc.).

From a practical point of view, it's often much easier to get your game running over TCP to start with and then migrate what unreliable messages you can over to a UDP stream when it's all working.

I see weight in you comment. (You folks sure like to link to that article btw.) Cheesy

[...]

You're right, and maybe I should have read the comments for his articles too.

You know what guys? I'll go with TCP after all. I could struggle with UDP for a long time and maybe by the end of the summer I would gotten a working reliable UDP system, but I think I rather want to have a working reliable game by then. If there are any problems with TCP I'm sure its for a good reason, and even if the headers are a little bigger that's not a problem for tomorrow when the Internet will be faster than ever. Thanks for setting me straight.
10  Game Development / Networking & Multiplayer / Re: DatagramPacket delivery system (UDP in Java) on: 2009-06-21 22:20:39
this is not... but you ask to do exactly what a TCP stream do, but ok let's forget about TCP [...] I dont think it is, and especially if you plan to use UDP, cause with UDP you will only care of the most recent pos of a player, so if an old pos arrive you can simply discard it or use it to better interpolate futur position.

What's good about having UDP doing exactly what TCP does is that you can remove/add fetures if you like. For example if it's important that all packets arrive, but not important that they arrive in the same order, there is a down side with TCP since you have to wait for lost packets to arrive before receiving the ones that did arrive. I am however strongly thinking about sending the current game states each time step instead of the events that occured in the time step... then I can "fire and forget" the packets. But I still need some sort of way to send some packets with guaranteed delivery, for stuff like chat messages.

UDP is a perfectly good choice for certain networking models. Take a look at the Book of Hook for a great explanation of how to do it all. You don't really need anything more than the Java standard library. The game state stuff is up to you. I'd combine it with a TCP connection as well, to send reliable control information easily, and just leave UDP for the realtime dynamic world updates. Cas Smiley

I've read that article (linked to it in the previous post), it's good. The down side about using both TCP and UDP is that it will (supposedly, I have of course not made any tests myself) make the UDP packets get lost more often. Also you need to open another port then, right? Or can you have both UDP and TCP traffic in the same port? I don't want to require the players of my game to open two ports instead of just one ("double the trouble").

I have tried JeNet now, it was a pain in the neck since it relies to SIX different things which you have to browse around to get from the web yourself. One would think they could at least link to the dependencies on their site. Tried getting "apache-log4j-1.2.15.zip", it wasn't even a jar file. I'm not a big fan of using other people's code unless it's in a jar file since the project gets... well, bloated.

I really wish there was a simple way to do this but it seems I'll have to code the ack/resend part myself. Sad Feels like I'm coding a tad out of my leauge, it wasn't that long ago I started coding Java and I'm afraid I'll code myself into a corner and then get stuck with flawed networking code and many wasted hours.
11  Game Development / Networking & Multiplayer / Re: DatagramPacket delivery system (UDP in Java) on: 2009-06-21 21:10:02
The thread got filled with "use X instead of Y"-replies, who would have guessed it? Smiley

I made a simple network game using TCP before, it was easy to do and turned out very great (100% synced). I was like, "Maaan!" when I figured I would have to change to UDP.

Without further deliberately trying to make this thread into a "UDP Vs TCP/IP"-thread (like http://www.java-gaming.org/topics/udp-vs-tcp-ip/608/view.html) I will tell you my motivation of using UDP in short (you did ask why).

I want to make a action game, and I want to transfer events of every time step from the server to the clients. I update the logic 50 times each second, which means I'll transmit a DatagramPacket to all connected players 50 times per second. (If that later turns out to be too much I will lower the logic to 40 times per second I guess.)

The size of each packet that is sent will vary depending on the events that happened in the time step. Now, I'm new to this whole networking thing so I'm not sure if my approach is the best one, but I think it is better to send only events to all players and letting them simulate what happens from the events instead of sending the location and rotation of every object in the game. Or is it...? In any way I need to transfer a lot of data each second and they need to arrive on time. From what I've read UDP will do its job faster than TCP, unless of course it fails (packet loss). The UDP header is smaller so it will also save some bandwidth.

I have read a lot of text that recommends the use of UDP over TCP for games.

http://staff.cs.utu.fi/~jounsmed/mcg_05/
+ PDF slides, lectures (lots of other interesting stuff there).

http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking
+ One good reason to send game states instead of events is that you can fire and forget. Keep pushing not-acknowledged data until they get acknowledged is also pretty smart, even if it increases packet size.

http://www.gamasutra.com/features/19990903/lincroft_01.htm
+ These guys started with using TCP but realized that they had to change to UDP. They sent a copy of the previous packet along with the last packet, this will remove packet loss problems unless two packets are lost in a row. As soon as a packet arrives out-of-order (and it is not included in the latest packet), resend requests start going out for the missing packets. I liked this solution, even if it doubles the packet sizes.

http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
+ This guy really pushes for UDP use in games, and explains why thoroughly. He does speeches about gaming, and writes his articles well. I recommend reading his "Networking for Game Programmers" series, they are well-written and actually FUN to read (that's rare). One thing he mentions is that mixing TCP and UDP is not recommended since it appears to be more packet loss for UDP then.

Also not all but most real action games use UDP instead of TCP. There has to be a good reason for that, so might as well try and learn to do UDP right and get into the the "right pool", so to speak. By using UDP I guess you also get a lot more control over exactly what is happening on the IP protocol.

Aaaanyway, I will check out javagamenetworking (https://javagamenetworking.dev.java.net/) and JeNet (https://jenet.dev.java.net/). I really don't like how java.net is structured, I think their layout is hard to navigate (I guess the fault might be a bit more with the different project owners, but if java.net had given a proper structure template to begin with not so many project sites would be in the state they are in). JeNet sounds especially interesting, doesn't seem so "bloated". Thanks guys. Keep giving me posts if you have em. Smiley
12  Game Development / Networking & Multiplayer / DatagramPacket delivery system (UDP in Java) on: 2009-06-21 17:22:25
I want to use UDP for my game networking. The problem is that I need all packets to arrive and I need them in the order they was sent. I started writing my own code that does this, but it's tedious. Then I got to thinking, "Hey, this is Java and the year's 2009 - this wheel should already be invented!". There should already be a ready-to-use "DatagramPacket delivery system" somewhere that I don't know about.

So, is there any such thing? Like a class that I just give the bytes that should go into a packet and who should get that packet, then it sends that packet and automatically handles flow control, resends (guaranteed delivery) and order-of-delivery.

My hope is high. Smiley
13  Game Development / Networking & Multiplayer / Re: Preventing cheating in network games written in Java on: 2009-06-21 17:03:41
So... what is the product/game you're making anyway?

Actually I'm just learning right now, trying to make simple "move and shoot" games in 2D so I get the hang of rendering game graphics and syncing across network. Learning ways of how to prevent cheaters is also a good thing to learn I thought, so I made this thread. Also trying to learn how I can use ProGuard, have a thread up about it but it's not really moving forward. Here's a link to that thread in case any of you who reads here are an expert. Wink http://www.java-gaming.org/topics/why-doesn-t-the-proguard-output-work/20582/view.html I have completed a small test game using TCP to communicate over the net, right now I'm trying to get the hang of how to make a game that communicates with UDP and that is turning out to be a challange. Might start a new thread about it soon.

I'm not sure I can explain it any more clearly, and the achievement is of course the devil of the detail. But here goes:

A technical solution to cheating is to have a secure third party which is the sole arbiter of the rules of the game. Right away this does away with 99% of the useful cheats you might have thought about. The typical situation is that the servers are hosted by yourself, and no-one else. The clients don't even have to obey what the server says - the server contains the state of the game, and the clients only have powers to influence that state via the interface the server provides. You can't speedhack, for example, because the server says how far you can move.

Secondly, to design a game where, given all the information that the client can possibly obtain, it does not matter how the client uses that information. Specifically, games that involve "aiming" and "reflexes" are prone to clientside hacking to do the aiming for you. To counter this you could have autoaiming on the server anyway, negating any advantage (which is what all the MMOGs do). And failing that, you resort to heuristics.

Heuristics is the science of making an educated guess based on the available information. What you need to do is collect information about the players' performance on your server, and then set a threshold beyond which it is probably the case that a player is cheating. A player that gets 100% accurate hits with the railgun every time when the rest of the players only manage 50% is probably cheating. And if not cheating then probably making the other players have a crap time. But automatically kicking players is unwise and unfair. Flag them as possibly cheating, and get all the players to vote. Check Soldat out for an example of this. Soldat uses all kinds of mixes of clientside prediction and arbitration and is famous for clientside hackery, so heuristics and voting play an important part in its gameplay. It even makes the game more fun.

Cas Smiley

Ah now, I get what you mean, thanks for clearing that up. That was a good addition to this thread. Speaking of Soldat, that is my favorite game believe it or not. I have high hopes of making my own game similar to that one. The anti-cheating in Soldat is however not good at all, and the network protocol is even worse. And most people are unable to discover cheats like reducing reload time by 50% so they won't vote yes on a kick, to notice that in the heat of battle you need to have played the game for months if not years. And you'd be surprised to learn how many that are just too dumb to vote people out, many times I've seen people NOT getting voted out even though they teleport to each player as soon as they spawn and knife them to death instantly. In later versions Soldat has made use of BattlEye, which finally made it so hard to cheat that not that many people does it anylonger, but in the olden days there was probably at least one cheater on any server at any given time. Well, almost. They still haven't fixed their network protocol however, a lot of times you hit someone without it doing any good, sometimes (more often than rarely actually) you can even make them bounce away from the impact but it still does no damage - thats the biggest problem with the game today I'd wager.

be careful to separate the physics(game logic) from the rendering(also involves physics) but only has to be good enough.  you only send as little information to render it 'right' which could well be jit before it comes into view. and handle/send if the player gets hit or not separately on the server, its a method to save bandwidh not cpu cycles. There are some papers avail on this, with respect to relevance here: it's in the best interest of the client to render/calculate it right. You(the client) can render it any way you want but the server veto's if you get hit. Beyond that it's useful for the player to get the right information(for dodging if projectile is slow, for localising the enemy if the projectile is fast(sound, visual feedback of impact). So messing with it becomes a handy-cap not an advantage. I suppose you could draw tracers to help but thats about it.

Maybe I wrote it badly, or misunderstand what you wrote now, but in what order things are drawn wasn't part of the post I made (the one you quoted). But your post made my think about exactly how things should be drawn for the user, if I just have a separate thread that draws the game (like all teachers have told me to have so far) one object might be painted one frame ahead while the previous was painted one frame behind the current object. Hm, I guess making sure not to paint the game while the game logic is being updated would be a good idea, even though it probably isn't noticeable in most cases. On thread can draw the frame while the other manages the networking part of the game loop. Off-topic but a important thought. Smiley

--

Well then, I guess this thread is going towards its end (for now). Thanks for all the tips people! If you stumble over some more good anti-cheat methods (that works in Java) remember to post them here in the future.
14  Discussions / General Discussions / Re: Messing around with the title bar of a JFrame on: 2009-06-18 15:47:44
Hm, here's something interesting, if I call "setUndecorated(false);" in the JFrame's constructor I get two title bars. Apparently the title bar I attach the MouseListener to is a fake one created by the look and feel I'm loading... Interesting, it should be possible to change it somehow...

Edit: Cool, I can disable the "X". I'm using a Substance look and feel, and by using a SubstanceLookAndFeel method in the JFrame's constructor I can get the JComponent of the title bar. Then I can disable the "X", like so:

1  
2  
JComponent titleBar = SubstanceLookAndFeel.getTitlePaneComponent(this);
titleBar.getComponent(3).setEnabled(false);


I bet I can add a mouseListener to the "X" button now if I want to. Smiley But I'll try to see if it's possible to insert new buttons first.

If you haven't heard of Substance yet, check it out: https://substance.dev.java.net/
With it Java applications can look really nice.

Edit: Well, it didn't go so well. I thought I could just add another component to the titleBar, that would have been logical since the titleBar is a JComponent. But no go. It's weird because I also can't disable the maximize button for some reason, maybe its nestled in some way. But even weirder is that doing "removeAll()" on the titleBar does nothing. Also can't change stuff like the background color. I'm bewildered. At least I got my "minimize to tray on right-click" behaviour on the close button, and since I'm now using the "getTitlePaneComponent(~)" method I'm pretty sure that it will work on all systems.
15  Discussions / General Discussions / Re: Weird MigLayout on: 2009-06-18 14:54:18
LOL Wink

Haha, I didn't notice that. Smiley
16  Discussions / General Discussions / Re: Messing around with the title bar of a JFrame on: 2009-06-18 14:52:57
This simply isn't possible in Swing.  The behavior you want is very platform-specific, you'd definitely have to write some JNI to accomplish this.

Also, I don't think the "frame.getLayeredPane().getComponent(1)" will work on all platforms.  At least, it isn't guaranteed to work everywhere.   Wink

The whole "right-click on the window close button" thing is not intuitive to me though.  Are there other, "real-world" applications that do this?  On Windows at least, some apps minimize to the system tray when the '_' icon is clicked.  You could certainly do that in Java easily enough - use the SystemTray class for the actual tray icon, and listen for WINDOW_ICONIFIED WindowEvents to toggle the visibility of your window.

I'm using a small ~150 KiB application called "TrayIt!" that I downloaded years ago from some place that makes it possible to right-click on all window's "X" button and then minimize it to the system tray. I use this feature all the time, it allows you to hide away stuff that you aren't working with right now and then bring it back later. I wish it was like that by default in Windows (that if you right-click any of the minimize/maximize/close buttons it will minimize to system tray).

Your post made me think a bit and you're right, it's not guaranteed to work on all platforms. I'm going to have to find another way of doing it... painting a small icon just below the title bar maybe? Too bad because I really wanted it to be in the title bar.

why not just hide it, and up top draw a "fake" title bar that looks like the real one but with what you want. Could be cool.

Yeah, but I mentioned in my original post that that is a bit messy, especially if you want it to look good and be draggable etc. But it's probably the only way to make your own title bar in a JFrame.

I never tried to do any of this until I saw your post so it's probably the wrong way to do it but still it shows it's possible. I use the minimize button to place it in the system tray and most of the code is from the SystemTray javadoc, the rest is hastily thrown together. I believe you could add/change the title bar buttons through a custom laf but I haven't actually checked and a fake title bar would probably be an easier solution.

I already knew how to minimize the JFrame to the system tray, but thanks for the code nontheless. It may certainly be of use for others reading the thread. Smiley I never thought of using the processWindowEvent() method though, interesting.
17  Discussions / General Discussions / Re: Messing around with the title bar of a JFrame on: 2009-06-18 04:25:50
Oh and before anyone suggests it, no you can't just catch mouseClicked events of the window's title bar and then figure out if you clicked the "X" from the event's X/Y location. Two reasons: First of all the close button's location is not guaranteed to be the same on all systems so it wouldn't have been that good of a solution in the first place, second (and primarily) the close button cunsumes the event so it can't be catched. Sad

As I have it now I just catch a right-click on the entire title bar and then minimize the window. It works but it wasn't what I really wanted. Here's the code that allows me to get the title bar (there's not that much that can be done with it, but it has "addMouseListener()").

1  
theJFrameInstance.getLayeredPane().getComponent(1);


This appears to only work if "JFrame.setDefaultLookAndFeelDecorated(true);" has been called, and if "UIManager.setLookAndFeel(~)" is not called the window may not be draggable and the title won't react to double-click.

Any way, that was a bit off topic, do go on. Smiley
18  Discussions / General Discussions / Messing around with the title bar of a JFrame on: 2009-06-18 03:47:49
I'v been surfing about, and it seems like most places agree: You can't change the title bar of a JFrame.

Some people suggest stuff like hiding the title bar and building your own (faking it with a JPanel). But it's messy and probably won't be perfect (especially if you are using a special look and feel). I thought I would ask you guys if you have any good ideas of how the content of the title bar can be changed.

I'm thinking of stuff like adding additional buttons next to the minimize/maximize/close buttons, removing the close button, making the maximize button react to right mouse-click and so forth. This can be done in other languages so it of course should be possible in Java. It may not be easy but it should be possible. And if it truly is so, it is too bad that you have to "fake it".

I'm posting this because I wanted to make it possible to minimize my JFrame to the system tray (that's "next to the clock") when you right-click the close "X" instead of left-clicking it (left-clicking it should still close the window as usual/pass a event to WindowListener). When that wasn't easy to do I instead wanted to add a extra button to the left of the minimize button (the icon would have been a dot) that would do the same thing. As you understand that wasn't an easy task either.

So, anyone got a good method of changing how the title bar works?
19  Game Development / Networking & Multiplayer / Re: Preventing cheating in network games written in Java on: 2009-06-17 19:02:05
First off, thanks all for the replies. This thread is heading for greatness. Smiley And thanks to those helping out trying to get people to stay on topic - how to prevent cheating in network Java games (and nothing else).

[...] And the thing poker bots need more than anything else is information about the game, so I could see why you would not want to have an array of integers tracking card types sitting around in memory for any bot to easily take a peek at. [...] Add in a few tricks like slightly altering the rotations/sizes/graphics of the cards, etc., [...] you will get a few people figuring out what the score submission URL is. If you "encrypt" the scores before you send them through and validate them with some sort of checksum and then ban IPs that send invalid checksums that will take care of almost all cheating there [...] Add a sanity check (it should take at least T seconds to get P points, where P is a decent amount above what you'd expect the best player to possibly get) and you'll stop almost all of it. Storing game replays and saving them to the server can take care of pretty much all of the rest if you've got the energy to implement it, and it also lets you play things back to the user [...] in an MMO things go slow enough that you can afford to have literally everything except graphics done on the server [...] There's not going to be any easy way to prevent someone from messing with the graphical output [...] I don't think there's any way to do this from within Java, you really have to make it platform specific.

Good stuff, especially the replay saving. That would serve as a sure way to remove all cheating in some games (except, like you said, if someone bothered to write a bot that plays as a human).

[...] I read an article on Gamasutra.com about anti-cracking - I know that's totally different than cheating, but the strategy they used was amazing. [...] Nothing easier than programming a game to crash on a failed SHA1 hash of some resource - or even the binaries. Well. That's where you get to nerf your game instead. [...] They thought they got the game running, and released the crack on internet. Needless to say quite some 'casual leechers' got fed up with the impossible gameplay, visited some forums, and found out what was happening. Seriously: they bought the game instead. So what can we learn? It is actually quite easy to figure out whether a wallhack is active. I mean, you have access to the framebuffer. You can use OpenGL Occlusion Queries if you're really lazy. And if you determine somebody is cheating, don't crash the game, don't show them a warning. No! Instead nerf their game. Make them randomly die, once every 10 minutes. Occasionally do not render an enemy. Give them half the healthpoints of a healthpack, slightly darken their screen, reduce the framerate at totally random moments, preferably when it hurts them most. The possibilities are endless. Besides that, it is fun to code. Just be very subtile, so they won't track it down to they own cheating.

Haha, that was a great thought. Instead of being betters cheaters would get worse, and even if the "cheat makers" later found out how to fix the anti-cheat there would already be flawed cheat-tools in circulation. However, as some people has pointed out in the thread, this strategy comes with a risk of the game getting a bad reputation of being broken if there are many cheaters that open their mouths on forums etc, and if you counter that by saying that only cheaters will get a broken game you alert the cheat-makers of what to look out for. Still a fun way of implementing anti-cheating though.

[...] Of course if you're writing an online pc game rather than a single player console game you've got the advantage of being able to patch easily and often. [...] it's much, much easier to write a simple counter to a well-known cheat than it is to try and build in all sorts of elaborate tricks that cover every eventuality. And because you're countering a specific hack you can get creative - like draing false players behind walls to confuse players using wall hacks.

Good idea, drawing things that non-cheaters will not see is one way of preventing people from using the cheat.

[...] Biggest problems in hacking? Well since we still a beta we do still have a few bugs people abuse. But we fix them once we know about it. Not really much other then the macroing as I said. We did have some problems outside the game, like abusing our payment system. But that's also fixed now. We make sure everything is server side. But of course this doesn't work for all games.

I see, best of luck with your MMO. I'm assuming it's this one: http://www.pokemonworldonline.net/

[...] xbox live, they don't ban you immediately, they simply keep gathering info and ban in bulk. This keeps ppl on thier toes and makes it hard(er) to figure out which method was detected. But it only makes it harder for cheat-creators to debug their stuff and keep ppl guessing if they got caught or not. [...] the latency problem goes away by time

Making it harder to make cheats is always a good thing. And it's always nice to keep in mind that ye, latency problem will get smaller with time - if something has pretty good latency now it will probably have great latency in the future. But one should remember that not all network parts in the world will get faster at the same pace (hehe), and the faster ones may always rely on the slower ones.

(Concerning encrypting variables.) [...] this approach was known/shown to be "very stupid, only relevant for lazy, stupid, or foolish people" as of approximately 10 years ago. (hint: Diablo1)

In what way? Who are you quoting that says it is for foolish people? Elaborate please. Smiley

"M2009: I've thought about that, but it doesn't work for things that should be barely visible (like if someone is 50% transparent)."

WRONG! (I'll leave it to you to work out how to achieve this. Hint: it's quite easy, and requries re-reading Cas's post and *thinking* about what he's saying.

"M2009: Also it will only work for servers that constantly pushes the location of stuff to everybody, not if the server want to save bandwidth by only telling the clients stuff like 'spawn a bullet at X/Y with this direction and this speed'."

Now, you're right there - but then, this shouldn't even be an issue. Are you sure this is an issue, or did you just imagine it might be an issue, and you've started worrying pre-emptively?

At you first statement: You guys seem to be very tight on this forum, aggressivly defending one another. How nice. I'm still not sure in what way I was wrong though, but I might indeed have failed to interpret what princec said, maybe he (or you) can repeat what he said in a simpler wording (with focus of countering your quotation of me)? Saying exactly how to achive it would also save other people time (for example a guest that reads this thread a year from now scanning for advice - maybe he can't understand how to do it either and just need quick advice?).

At your second statement: I'm pretty sure this is an issue, say you have a 2D world and someone fires a bullet just outside of your view, to the right. This bullet passes inside view in the top right corner of your screen and then disappears at the top. Then the bullet hits a box outside of view which falls down, gets in view and then crushes your player. Should the server just say "make this bullet" and let the client simulate the physics, or should it say "create a bullet" when it gets into view, then "remove the bullet" when it gets outside of view, and then "create a box" when the box comes falling into view? Or should the server tell the client to simply draw a bullet/box for each frame that it is visible (no physics calculation needed at all from the client).
20  Java Game APIs & Engines / Tools Discussion / Re: Why doesn't the ProGuard output work? on: 2009-06-17 17:31:21
Thanks for the info, appreciate it.

My binaries.jar was created from the Windows 32 JOGL binaries "jogl.dll" and "jogl_awt.dll". The "localhost" argument was for connecting to a server that was on my own computer.

About the permissions, I will need files to be written to disk (player profile data for example) and for that I guess I need special permissions. Where would these files even be saved if someone ran the jnlp file from a home page?

Can the application be run from a computer with no Internet? Like if somebody download the game RAR archive from my site, then put it on a disk and takes the disk over to a isolated computer without a network cord, then extracts the game there and tries to play it in single player. If the DLL files needs to be downloaded I don't think a jnlp file is the right solution for me. It can be noted that I don't really need the game web startable, I want the players to always run it from a game folder on their computer.

Which I guess brings us back to the original purpose of the thread, how do I use ProGuard to shrink and obfuscate my exported game's runnable JAR file? How can I tell ProGuard to not touch the classes that I haven't written myself - if only my code gets shrunk and obfuscated the JOGL part of the application shouldn't break, right?

I'm very much willing to learn how to use ProGuard "properly" (without the GUI), but I'd like to have somewhere to start. Does anyone have a example ProGuard script that shrinks/obfuscates a selected class inside a jar file?
21  Discussions / General Discussions / Re: Weird MigLayout on: 2009-06-17 17:04:46
You have a point but it's the developers of MigLayout that wants it to be included in the JDK the most, maybe they feel it's pretty much complete? I mean, Swing's one thing but how much further can a LayoutManager really be developed after a certain point?
22  Discussions / General Discussions / Re: Weird MigLayout on: 2009-06-16 18:46:48
Try

1  
new MigLayout("insets 0, fill")


And if it works, slap yourself for not adhering to RTFM, since I never heard of MigLayout and just took a look in the QuickStart.pdf  Shocked

I slapped myself hard on both cheeks. Seriously.

At least this thread will help introduce some to the MigLayout. Cheesy Help making it an official part of JDK 7! Cast your vote here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6530906
23  Discussions / General Discussions / Weird MigLayout on: 2009-06-16 16:43:17
Not sure where to put this so I put it in General Discussions and hope for the best.

What you are seeing from the attached image is some weird behavior from MigLayout, my favourite LayoutManager in Java (I'm sure I'm not the only one).



I have placed a JTextArea inside a JPanel. What's weird is the extra space that appears between the two borders. It should not be there! If I place the JTextArea in the north/south/west/east it is not there, but it is there when I place it in the center. I need it to be in the center since I want it to be able to grow both horizontally and vertically.

Here's the short piece of code:

1  
2  
3  
4  
5  
6  
7  
8  
9  
public class Log extends JPanel {
    private JTextArea ta = new JTextArea("haha");
    public Log() {
        setLayout(new MigLayout("fill"));
        setBorder(BorderFactory.createLineBorder(Color.BLUE));
        ta.setBorder(BorderFactory.createLineBorder(Color.BLUE));
        add(ta, "grow, center");
    }
}


If you haven't heard of MigLayout before, welcome to layout heaven. Smiley http://www.miglayout.com/

Anyway this is the first time MigLayout haven't made sense to me, why is there 7 pixels of space between the borders? Is it something with JPanel that needs tweaking? Some sort of padding maybe?

Edit: Fixed tabs, added image above.
24  Java Game APIs & Engines / Tools Discussion / Re: Why doesn't the ProGuard output work? on: 2009-06-15 21:59:41
It was a lot of work and in the end I failed.

By using this tutorial: http://www.cokeandcode.com/webstarthowto

I made this JNLP file:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
<?xml version="1.0" encoding="utf-8"?>
<!-- Test for Astro Prime Web Start Deployment -->
<jnlp spec="1.0+" codebase="file://localhost/C:/Users/Me/Desktop/test/" href="test.jnlp">
  <information>
    <title>Testing</title>
    <vendor>Me</vendor>
    <homepage href="http://www.webcrawler.com/"/>
    <description>This is a test.</description>
    <description kind="short">A test.</description>
    <icon href="testpic.gif"/>
    <icon kind="splash" href="testpic.gif"/>
    <offline-allowed/>
  </information>
  <security>
    <all-permissions/>
  </security>
  <resources>
    <j2se href="http://java.sun.com/products/autodl/j2se" version="1.4+"/>
    <jar href="test.jar"/>
    <jar href="jogl.jar"/>
    <jar href="gluegen-rt.jar"/>
  </resources>
  <resources os="Windows">
    <j2se href="http://java.sun.com/products/autodl/j2se" version="1.4+"/>
    <jar href="binaries.jar"/>
  </resources>
  <application-desc>
    <argument>localhost</argument>
  <application-desc>
</jnlp>


It launched, but crashed without any message (I just print stack trace on exception and exit the application). I guess it's the same old problem, that OpenGL can't be found.

I don't really like this, first of all it doesn't work second I need to distribute a lot of files (binaries.jar, gluegen-rt.jar, jogl.jar, test.jar, test.jnlp, testpic.gif - and that's only with the win32 binaries!) and thirdly because I needed to sign the GLU and JOGL jar files which felt just wrong. Also the whole signing business was just a pain in the neck, and exporting a million jar files etc etc. And once I actually get this to work there's no guarantee that ProGuard would not screw stuff up so it stops working.

Is there really just no way of just exporting a executable jar file like I used to and then tell ProGuard to skip everything that is GLU or JOGL related? There would be so much sweeter to just have to do three things before I can distribute instead of having to do thirty things.
25  Java Game APIs & Engines / Tools Discussion / Re: Why doesn't the ProGuard output work? on: 2009-06-15 20:45:16
Thank you very much, I'm glad someone is trying to help me in detail!

I'm don't know what you meant by Android applications?

Also the jnlp file, how will it make the game work without DLL files? Say one want to play the game on a computer without internet so nothing can be downloaded by jnlp, won't a exception be thrown as soon as the game tries to draw a frame in JOGL since the binaries are missing? I have never made a jnlp file before, but am willing to learn since people will be able to play my game online with one click. Maybe you have a link to give me so I can build a proper jnlp file? It would be great if the user don't have to place it in a fixed place on the hard disk also, since in some places they won't be allowed to do so (such as schools).

I'll try to export only my code in Eclipse now, however I still don't feel confident in this area.
26  Game Development / Networking & Multiplayer / Re: Preventing cheating in network games written in Java on: 2009-06-15 19:39:56
Continued post ("The message exceeds the maximum allowed length (10000 characters)."):

Thanks for your honest response. I deeply appreciate it. You are so right: I'm not an expert, and I think I am smart. Way to make friends, too.

I wonder what you thought of encrypting variables, as this raises the bar quite a bit against the 'find this value in RAM and modify it' attack - the fact that AoE AoK 2 used it, which can't be ignored, might change your mind, and accept this little bit of information from a clueless person like me. It's way better than making your app behave like a rootkit, poking in the sys internals to somehow make it secure. We all witnessed how SecuROM was loved by the community, and how effective it was - then everybody was scratching their heads when EA decided to dump it.

Clientside security: less is more

Listen, I'm sorry for hurting your feelings. I was just disappointed that the first reply I got in my thread was something that I had asked not to recieve, no disrespect meant. About your encryption idea it slipped my mind, it was a great idea. It will surely make it harder to use cheat tools, although it will also surely require more work from the programmer and it'll slow down the application some (I guess). Thanks for the code, that's something I'd like to see more of in this thread.

http://en.wikipedia.org/wiki/GameGuard is similar to SecuRom and they continue to use it. The "Known blocked applications" make me laugh.

Ah, external anti-cheat software. That's one way of preventing cheating, although it feels a bit bad to rely on other people's work (at least for me since you lose control), and it might require the user to run two applications instead of just one. GameGuard is a typical Asian MMORPG anti-cheat in my book. Cheesy There is also BattlEye (http://www.battleye.com/) which is the same kind of application, I don't know if it's better or not but it is free (I'm assuming GameGuard costs money?). I have thought a lot whether or not I should go with BattlEye, then I started this thread in high hopes of someone to tell me how anti-cheating can be done in Java.

I know that, my suggestion was more of a joke. BUT I have seen full 3d games work fine. Some cloud based server gaming company.
Though for your example, no idea why they would do that for a card game, they should be easy prevent cheating in them.

In the MMORPG I'm in charge of we do have some cheating problems, but only minor things like bug abusing. Everything is controlled by the server, so we don't have any real problems.
Afk macroing would be our biggest problem if I had to name one, which we hope to solve with random events.

Joke or not, it was still a good idea. Not scalable perhaps but if someone wants to do a very small game, like 50x50 pixels, they can now get a solid anti-cheat tip from this thread. Smiley Btw, if you had to name three (or more) of your other biggest problem, what would they be? It's interesting.
27  Game Development / Networking & Multiplayer / Re: Preventing cheating in network games written in Java on: 2009-06-15 19:39:29
Thank you very much for all your replies! ...Nuclear launch detected:

On the visibility side, if a client shouldn't be able to see something, then don't tell them about it. Looking through a wall won't help them if what is on the other side they know nothing about.

This is a topic that has come up here before, and the general conclusion (from memory) has been that you can't reliably prevent it. All you can do is protect information they shouldn't have, and try to detect anomalous behaviour. ie, aim bots will probably be rotating the player faster than a player should. so if your server spots a player that moves too quick, it's an indication that something might be up. You have to be careful though, they may just be good. You will need to base your cheat detection rules on your own game rules.

Endolf

I've thought about that, but it doesn't work for things that should be barely visible (like if someone is 50% transparent). Also it will only work for servers that constantly pushes the location of stuff to everybody, not if the server want to save bandwidth by only telling the clients stuff like "spawn a bullet at X/Y with this direction and this speed".

What Riven is telling you is the truth. You cannot avoid cheating. End of Discussion.

Therefore focus on giving the players that don't cheat a good time - and finish the game. Make it worthwhile not to cheat. *Then* implement mechanisms that make it harder to cheat and implement mechanisms for detecting cheating.

Well, I said that myself so I know it's the truth. But there are still means of preventing cheating, not all cheating, but a lot - so there's always room for discussion. And making cheating harder is always a plus. And yes, even if you focus on making the game fun first and worry about the cheating later, it's always a good idea to know that you CAN prevent cheating later. Knowing about how cheating can be prevented later will make it possible to avoid programming in a way that will force you to rewrite code later.

RuneScape? I don't think removing textures etc would prevent cheating - the main issues with cheating are bots and real-world trading (gold farming). However, they do have frequent client updates which reobfuscate the code and the client-server protocol, so you can't use old clients and have to re-deobfuscate each time. It's not completely effective, but it raises the bar in comparison with one-off obfuscation.

Ah, here we go - that's one way to prevent cheating. It'll increase the workload alot, but it will render all not constantly updated cheatengines useless after a period of time. Good idea.

Riven is so much of an expert of so many things here, you should be glad he answers you Shocked Your reaction is inapropriate!

Furthermore he is right: you can't prevent cheating!

First make a game that attracts players. If someone really is cheating, you have to find out what hole or game mechanics he is abusing and try to make it harder to do so. You can't secure your code before this is happening. It's more like in virus/malware protection - you can only fight it once you know it. This is a day to day job and will never end (if you manage to get a game out, that people consider worth of cheating - which might be the hardest part overall!)

I know I sounded a bit rude and that was the point since I warned people from just saying "you can't do it". No disrespect, I just wanted to discourage more posters from just saying "you can't" (it's obvious I failed to do so). Concerning your last paragraph, yes I know this but you're missing the point - I want to know if there are ways of preventing cheating in Java just like there are many ways to do so in C.

Design the game both technically and mechanistically so that there is no such thing as "cheating" or "cheating" confers almost no benefits. Then use heuristics to detect any edge cases and flag them.

Technically, that's having all logic serverside, and treating the client like an untrustworthy mushroom, kept in the dark and fed on shit. Or specifically, only information that the client should know. The client should be able to make no decisions that affect the game.

Mechanistically, make the client capable of doing anything that a cheater might want to do anyway with the limited information available. A trickier and more esoteric side to it.

Heuristically, if someone's performance falls outside 99% of the expected range of performance persistently then have the server flag them as a possible cheat and call on the other players to vote them off. This works on various levels - firstly it's not automatic: if none of the other players cares, neither should you. Secondly if they actually aren't cheating but are simply so bloody good they're pwning all the other players, they can boot the smartass out anyway and enjoy themselves more. Thirdly they might all just be a bunch of friends all running the same cheats for kicks on that server, so let them have their fun, they won't vote each other out. (And the heuristic will change over time of course).

You've probably figured now that FPSes are therefore almost entirely impossible to secure because of the technical requirements (ie. you need to send data about entities an client can't see a few millis before they pop into view to prevent, well, popping, which means a transparent wall hack will confer cheaters a tiny, tiny advantage), and the only mechanical solution is to actually not have any walls which would be a bit pants, so you're left with heuristics.

Cas Smiley

Games shouldn't be designed with "is this exploitable by cheaters", just imagine how much good stuff would have to be cut away. Some games can be designed so that cheating would give no benifit, but others just can't. The vote idea is one way to prevent cheating, however there should be better options since what if 5 cheater friends joins a server with 4 non-cheaters? The cheaters won't vote each other off. And if the server suggests that you are cheating when you are just being skilled you might get voted off unfairly, which will cause frustration in someone that otherwise loves the game and might be a strong supporter that will try to make others start playing the game (I've been voted off just because I'm deemed too good several times in one game, it's not that fun but there's not much to do about it unless kick vote should be disabled).

What about the client just sends the controls and server just sending pixel information, that solves everything  Tongue

I have seen business starting to that...

Sounds like that would demand a lot of processing power from the server and it will increase the bandwidth requirements through the roof. But it's a sure way to prevent cheating. Smiley

IMO, as already mentionned the only good way to avoid cheating is to perform logic server side.

so, I would recommend to perform game logic/rules server side aswell as a subset of them clientside (to avoid problem on network latency) and send "correction packet" to client when player movment/action is not acceptable.  this is as far as I know what is done in network game.

All of that is not related to Java itself but rather to the fact that the client is God for all things that are client side, you wont get much more problem to secure a java softwer than you will get to secure a C++ one.

EDIT :
about your checklist... it will increase hugelly your game cost and will bring new bugs, also one usefull attack is to use a proxy and monitor packets and then to make the difference between packet sent to locate where "active information" is transmitted, there is nothing against net sniffing in your list... so you are using a metal door with paper wall.

Interesting addition to the "keep logic on the server" argument, it would keep the bandwidth down but require a bit more calculation on the server to see if the players are kinda in the right place. Also the players need to send his position now and then to the server so the server has something to compare against, unless of course the server just sends a "sync" package now and then which probably would be best. This is not something that can be done when precise things are required though (such as fiering a bullet through a small hole in a wall). Concerning the checklist, let's pretend that I am a big company and want to do UT2010 in Java, adding extra cost for anti-cheating system won't be a problem. I just want it to be doable. And about the net sniffing, sure it can be done but it isn't very realistic since you need to catch the correct packages sent to other players. As we know not all cheating can be prevented, but we want to make it as hard to do as possible, and doing what you say is already pretty hard as it is. Tongue Guess we can always add encryption to the traffic if we want to make it even harder.
28  Game Development / Networking & Multiplayer / Re: Preventing cheating in network games written in Java on: 2009-06-15 03:45:16
"keep all logic on the server"
"you can't prevent all cheating" and think they're being smart,

There you go.

Making a game with players is hard enough. Don't waste time on cheaters, until it happens! It's just a big time waster, like, you're wasting time, which you could spend on creating a game, and not waste on cheaters, don't waste your precious time on cheaters, it's such a waste - I think I made my point.

and cheaters have more time to figure out things anyway.

If you want to 'secure' some global variables, which are very easy to lookup (and thus manipulate), build some SecureInteger class, and fiddle with the bits, a bit. This is what was done in Age of Empires 2.

You think you're so smart...

Seriously though, I want to know if there is some way to prevent cheating in games built in Java. Obviously you're not an expert but there may be people that actually knows about this stuff, since it is very important.

I know there are MMO games in Java (at least one, don't remember the name but it is many years old and still running), how is cheating prevented there? What prevents the user from, say, removing all ground textures and thus being able to see through mountains? I'd like to believe no company will make a serious game in Java unless there is a way to prevent at least common ways of cheating, especially if there is money involved somehow. And if many people cheats in a game a lot of real players might quit out of frustration, if the game is one of the pay-to-play brands that means lost revenue for the company and/or less motivation to develop the game further due to the drop in players.

This is not about me wasting time making the game cheatproof, it's about not wasting time making a game in Java that later will be completely raped by cheaters so no-one will play it.

Edit: Inserted your two quotes of me inside my quote of you.
29  Game Development / Networking & Multiplayer / Preventing cheating in network games written in Java on: 2009-06-15 00:00:55
In this thread I thought we could share some ways of preventing cheating in online java games (for example of many human players are trying to kill each others, how can you prevent one of them from seeing through walls/invisible objects or having zero reload time etc).

I'm new at this so I don't really have any tips to give, other than the "keep all logic on the server" (like the server receives a click event from a player and then generates a fire event which is sent to all connected clients). This puts a lot of work on the server's shoulders however and will still not protect from cheats that changes visibility of things (if a player is supposed to have 10% visibility the cheat could make it display at 100% regardless of what the server is saying since it's client-wise).

I saw a good anti-cheat checklist which I will now quote:

Quote
1) Open all other processes, and hook their WriteProcessMemory functions so that they can't write to the memory in your game's process. Done right this one step will block 90% of all cheats and cheat engines.

2) Do the same thing, hooking the various mouse and keyboard emulation functions. This will prevent a lot of aimbots and other types of automation bots.

3) Hook into the VirtualProtectEx/VirtualAllocEx/etc functions in your game's own process and monitor which modules are changing protection levels or allocating new memory chunks. You have to be crafty with this in order to prevent it from being too CPU intensive when your game does a lot of allocations, but it can be done.

4) Hook into the LoadLibrary functions and monitor any DLLs that are being loaded dynamically, to prevent DLL injection.

5) Use some lightweight polymorphic encoding on your game connections.

6) Use some anti-debugging techniques to prevent debuggers from attaching to your processes. Google anti-debugging and you should be able to find lots of stuff.

7) Use a custom proprietary PE packer to prevent useful disassembly of your game.

8) Hook into your OpenGL or Direct3D functions and methods that deal with transparency and alpha blending.

9) If using shaders, checksum your shaders and the shader constant values.

10) Use additional occlusion culling techniques on player characters to prevent them from being rendered at all when the line of sight to them is blocked by other geometry. It may or may not help with your performance also, but it will prevent many wallhacks.

Source: http://stackoverflow.com/questions/960499/how-to-prevent-cheating-in-our-multiplayer-games

This is a good list IF you are skilled enough to implement it by yourself, which I am not. Also, this list is more for languages like C and not Java. Maybe one can use a Java Native Interface to implement the anti-cheat part of the game, however I'm again not good enough of a programmer to be able to do that.

Java Native Interface is from what I understand making a EXE in for example C and then have C call Java mehods. More information about it can be found here for those interested: http://en.wikipedia.org/wiki/Java_Native_Interface (A side track of this thread I suppose, but maybe one of you can use it to prevent cheating in Java games?)

So, anybody with experience willing to share their knowledge? I bet this is something a lot of people on this section of the forum would like to know better. I know some may think they should post "you can't prevent all cheating" and think they're being smart, but if we could at least make it impossible to use the most common cheat engines we would get rid of a lot script kiddies (I'd guess 99.9% of all cheaters are just using a general-purpose tool someone else made).

For good measure I will make what I wrote above into a question:

How do I prevent cheating in multiplayer Java games?
30  Game Development / Performance Tuning / Re: ProGuard tuning on: 2009-06-14 16:04:33
Okay, thanks. I'll remember that, sounds smart.
Pages: [1] 2 3
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (48 views)
2014-04-15 18:08:23

BurntPizza (44 views)
2014-04-15 03:46:01

UprightPath (60 views)
2014-04-14 17:39:50

UprightPath (42 views)
2014-04-14 17:35:47

Porlus (58 views)
2014-04-14 15:48:38

tom_mai78101 (81 views)
2014-04-10 04:04:31

BurntPizza (140 views)
2014-04-08 23:06:04

tom_mai78101 (240 views)
2014-04-05 13:34:39

trollwarrior1 (200 views)
2014-04-04 12:06:45

CJLetsGame (207 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!