Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  3d transform data thru socket  (Read 4275 times)
0 Members and 1 Guest are viewing this topic.
Offline MickeyB

Senior Member




my game will work, my game will work!


« Posted 2003-01-04 00:59:37 »

What would be the best way to send my location data from the client to the server and back again?  

I have tried 3 different client server setups and just cant find a working scenario.

I have a client app that is "playable" and will gladly send the source to anyone who would like to critique or advise on how best to network it.  Just email me if you would like to see it.  I am at worldbuilder@comcast.net

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #1 - Posted 2003-01-06 23:01:43 »

Piece of cacke to get something generic up and running. It really depends on what technology you want to use. Personally I wouldn't recommend RMI for this. All you need to do is encapsulate your positional data into bytes on the client, send that data to the server, and have the server multicast that information to the other clients.

Note: this will get you something running quickly. It is however, NOT the best way to solve the problem. Scalable server design is not something that can easily be addressed in a single thread, and it is something that is integral to the design of your application. Get your basic example up and running (look up Socket and ServerSocket for quick ways to handle this) and the pop open a thread in the networking section when you're done.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #2 - Posted 2003-01-07 00:05:18 »

I do just want something up quickly.  Where I was running into probs was getting the rotation on Y from the client and sending it.    AND when to grab that data fro the client , ast what pint to send it and how often.

I was using a Movement behavior and Keyboard behavior.  Cna this be done from a behovior or should I wirte a non-behavior class for it.

I understand the basics of client/server activity, just not with a java3d client.

Did I lose ya?

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #3 - Posted 2003-01-07 03:02:18 »

There for sure, as so often, is no single answer.

I personally transmit hand-coded position/kinetics data for a full 6dof motion applying a deadreckoning scheme that considers up to 2 derivatives.
The dead reckoning automatically tells me when to send data (not so often hopefully), avoiding latencies caused by fixed time slices.

My 'server-loop' is triggered when I received data on one or more lines (when the Selector returns 0).

This way, theres no (or only few) latency introduced by the server, although sometimes a small integration time would be nice hopefully resulting in less messages to send.

Technically I transmit them with the NIO api, which is told to be the most efficient these days. Not more than 2 threads are needed. Maybe only one on a server (wait-for-message, handle-it, wait-for....).

Now it depends on your needs. If you e.g. have a simple Quake-like motion you can be even off sending just motion commands (go left, forward, turn ....).

Many games even do this in fixed timeslices. Thats brute force and ugly to the max, but it deservs simplicity Smiley)

Did I lose ya?

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline lefty

Senior Newbie




Java ees kewl, man!


« Reply #4 - Posted 2003-01-07 03:28:57 »

Quote
Technically I transmit them with the NIO api, which is told to be the most efficient these days.


Efficiency is not the same as performance. More specifically NIO is the most scalable, since the non-blocking nature does not require you to spawn a new thread per client. But that scalability comes at a price, performance.

So, if your non-NIO system would only ever have a couple of client threads (as opposed to the thousands needed for a web server), NIO overhead is probably not worth it.
Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #5 - Posted 2003-01-07 14:00:25 »

My current game app runs very smoothly.  You drive the "cube/avatar" and turn right or left, forwards or
backwards.  As long as a kep is pressed, you are moving, multiple key combinations give you combined
movement. ie; up arrow and left arrow = move forward whil turning to the left, and so on.  You get the picture.
I have a KeyTypedBehavior and  MovementBehavior(both extend Behavior)
The KeyTypedBehavior WakesUpOn keypressed, and the Movement WakesUpOn frames elapsed(0).

Space bar fires a single projectile by capturing the current transform of the "cube/avatar"
and applying it to a new object(smaller cube)  then move it forward for x number of seconds
then remove it frm the scene.

Ignoring some collisions issues with walls(which I am not concerned with right now), it runs exaclty
like I want it to.

At what point in that scenario should I send data from the client to the server?

Should I send x,y,z, and the matrix[16] of the player to the server or do you think keypresses = send("turn left"), send("turn right")
would suffice?  

considering you could be turning left and moving forward. Will this keep it accurate enough for shooting at
another player?  An "arena" will have a max of 16 players.  Right now only one arena will be active at
any one time.

And yes Quake-like movement is fine, I use keyboard only.  Arrows for movement, possibly the shift to
boost speed, "tab" or "space" for fire and "alt" to activate shields.  

I have done this in a 2D realm sending int's for x and y and double angle to server using a thread that sends the data 3-4 times a second
and the server is on a 30 ms loop sending all data to all players(with a little, very primitive dead r).

http://www22.brinkster.com/mbowles/  for the 3D source code.  Once unzipped, nav to folder and type java AWTFrame  

You will notice a lot of the code is J3D tutorial(thanks Justin)

and many, many thaks to those of you here.

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #6 - Posted 2003-01-07 14:21:06 »

Quote

But that scalability comes at a price, performance.


Where's that from? What kind of overhead does it impose? I think the ByteBuffers are very slim and fast!

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #7 - Posted 2003-01-08 04:44:18 »

One thing you should not assume is that you will need to (or want to) send every single packet from your client to your server. Doing so will simply drown the server in packets as the number of clients goes up.

Unfortunately what you're asking is a very application specific question. If its really necessary for you to send that level of detail and multicast it to the other clients, then you have to send it and will have to design around that. If its only necessary that other clients have the idea that 'client X is turning left' you can do that as well - but be careful! I can already see that you're starting to write a fair amount of code without really designing/thinking about/specifying what you need. This will result in unnecessary hardship during your development cycle.

What I would suggest before we continue is that you write down what your requirements are. What information will be necessary for clients to relably draw the state of other clients? What assumptions can I make about the state of entities in my world so that I don't have to transmit that information. For example if an object can only turn so fast, you may not need to transmit every discreet rotation to other clients. However if you find that you absolutely have to see every degree movement - put that into your design as a hard requirement.

Hopefully you see what I'm getting at. Before you can really talk about what you want to send - you need to really reconcile what you absolutely NEED to send. I'd be happy to go through that process with you in this thread if you desire.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #8 - Posted 2003-01-08 12:37:02 »

Will do.  I'll put that together today,  and thanks.  Will post to this thread as soon as I put them together.

Its a very simple concept, so you are probably right, I am probably overdoing it.  

More soon.


MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #9 - Posted 2003-01-08 14:08:52 »

If you have seen the code running, you have the basic idea of what the client game screen should look like, minus a chat area at the bottom (this is where login and chat will take place.)

Desired functionality is as follows:  Player will use the arrow keys for movement, tab or space to fire projectiles (these may varies in types).  When pressing the s key, shields will come on based on how much shield energy you have.  Up to 16 other players can be online at one time.    As a player logs in, the server will assign him a team/side based on game balance.  A match will have a time limit(or goal, capture the flag or something).  When time is up, players will be scrambled to balance the teams again.  Until there are sixteen players online, new players can join at anytime and will be entered into the appropriate team.  When a player dies he will get a 10 second countdown and re-spawn on the same team, at the spawn/entry point for that team.

Code side: Since I am using cubes (Cube Wars is the planned name, and there is a story behind that), and a flat plane playing field, no terrain data is needed, nor will there be any zoning.  When a client logs in(username and password check), he will need the universe data sent to him to synchronize his client app.  That is location of all objects in the universe (projectiles and players).  The new player is appear to all other players and to himself in the dedicated spawn location for his team. He can then start playing.  The data that the client sends to the server and the data the server sends to the clients needs to be accurate enough for real-time shooting.  Quake III Arena, Tribes 2, Sonys Infantry (most like this).  After all objects have been synchronously sent to the new client, he should send his movement changes(turns, move forward, move backward, stop) and when he fires a projectile (the projectiles position and transform3D at launch should be sent to server, then sent to all players), it then becomes another universe object with only a straight line movement at a constant speed.  I want server and client load to be the minimum needed to maintain shootable accuracy, attempting to elimnate the -hey your bullet was nowhere near me and I got hit!!- or - I shot you three times and you didnt go down-, etc. I know lag can cause this, but I dont want the code to be that off initially.

Have I given you what you were looking for?

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #10 - Posted 2003-01-09 23:26:29 »

That helps. Okay, here are a few things we can start to work on right away. There is no motion in the 3rd dimension so everything we need to do becomes a MUCH easier 2D problem. All we need to send is the x,y, and rotation of the object - 3 floats [notice how the requirements are getting down our data requirements]. We probably also want to send velocity so we can add that in as a 4th float.. So now we can describe a player as some playerID and an ordered set of 4 floats.

Since our player can be in one of 3 states ( normal, shielded, firing ) we can encode that information in a char - where each int value represents one of these states so clients can remotely draw what's going on.  So really what we have is:

PlayerState
float x, y,  rotation;
char state;

From what I was able to get from quickly reading through the requirements this is what you need to send for each player playing the game. More on what you'll have to do as we progress to ensure a non exponential sending pattern as we proceed.

What I would suggest for now is having a data structure that contains all 16 player's PlayerState structures transmitted at all times (this is NOT code you'll be keeping for too long but enough to get us started).

Since your game takes place on the same plane (players cannot be above or below other players... this works for height field maps as well), you don't necessarily have to transmit a transformation matrix for your projectiles either.  If you assume that they always travel with the same velocity, you don't have to transmit that information either since all the clients already know that information. It doesn't sound that projectiles have any particular descriptive details that we need to send to other players so we won't put that into the protocol right now.

ProjectileState
float x, y, rotation


You may be a little confused about how you will move the projectile with just the rotation. Since what we have is fundamentally a 2D problem we  can assume that this rotation is an angle from some plane and that the projectile is moving in this direction. Pick the bottom of your map and determine your angle of motion from this information against this 'world edge' plane. If you have trouble conceptualizing this, lemme know.

So now in the simplest case your packet is

MessagePacket
- source playerID
-PlayerInfo (16 PlayerState structures)
-# active projectiles
- ProjectileInfo ( n ProjectileState structures )

This is pretty much the state of the world at any given time. Yes it may seem large, but really its not. Let's not jump into 'real' optimizations yet in any event. This is a learning excercise so when you feel you've got this part down - lemme know and we can move onto the next step.




http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #11 - Posted 2003-01-10 14:56:46 »

I tried to send you a message, but my son hit my power button!!! So i'll re-comment here...

I may be confused a little.  If I am navigating forward into z, would't we need z also, and would this make y constant?  I guess if you fire up my app at its currnet stage(link above), can you tell me if the green grid is x or z.  I thought is was on the X plane, and that you would travel over it by increasing, decreasing z, but I could be (and probably am) wrong.

Other than that , I think I have your concept so far under control, and it makes more sense than what I was trying.  I am under the impression you are talking UDP packet for multicasting?

If you are able to download my source, use aroows for nav and space to fire.  The blue cubes can be hit by projectiles.

edit:   I have always done client/server games with the "mud" concept on the server side, loop thru all players and at each player send the data by again looping thru all players with DataInputput and output streams sending ints.  What would be the best data structure to use for the MessagePacket and the Player and Projectile states? i.e what should a PlayerState structure look like that you would pass to the messagepacket?

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #12 - Posted 2003-01-10 18:07:23 »

If you use y as up (and not all people do) then replace z with y. The thing to note is that you don't have to keep track of height (moreso than x, y, or z) since you're not concerned with players over other players or being over the map or anything.

For what its work protocol wise, you may want to start off with TCP. In the average case its not going to hurt you and is actually beneficial for our early work since UDP is likely to chop up our datastructure into smaller pieces that won't all get to the destinations at the same time. We can get to UDP a little bit later, but adding that part in now will more than likely just serve to confuse you because it brings in other issues with respect to reliability and synchronization that we don't necessarily want to tackle yet.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #13 - Posted 2003-01-10 18:36:16 »

Sounds good...I think I understand you.  Point is we dont have 3 dimensions to deal with since one of them is constant.

I have just completed a very basic set of classes in the server package:

Server
PlayerManager (keeps a vector of playerthreads)
PlayerThread (holds the socket connection for player)
Player extends GameObject (with char state)
GameObject (has floats x,y,rotation, and int objectID)

using TCP and it fires and waits for a connection.  telnet causes a successful playerthread and player to get created!  If you would like to check them out, let me know.

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #14 - Posted 2003-01-13 04:57:32 »

Get a stable build together for Friday and I'll sign on and play a game with ya Smiley

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #15 - Posted 2003-01-13 11:55:21 »

I have a few questions, but here s one of them...

DOn't know if you have seen my client code, but I have a KeyTypedBehavior taht wiats for keystrokes.  Those keystrokes set movement variables to true or false for different move directions.  The Movement calss extends behaviors and waitsOnfFrame(0) then does the move based on the true false combinations.    At what point in that process should I send the client data piece to the server?  Should I not have a mevement behavior since movements are coming from the server?

and yes It seems I have having a little trouble grabbing the angle from the "world edge"  Here is a screen shot.  Player is green, projectiel is white, blue is generic obstacle(not in game).   Movement is along green grid. Camera follows player.


MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #16 - Posted 2003-01-16 11:28:22 »

at what point in the client shoudl I send data to server?

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #17 - Posted 2003-01-17 19:52:36 »

That is another 'up to you' type question. You want to send the data often enough to ensure your simulation resolution. Many people try to do this once per frame, and it may work for you right now - but later we will tune that down when we get into the fun of UDP, missing packets and dead reckoning.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #18 - Posted 2003-01-17 20:00:06 »

sounds good, I'll try by frame for now.  oh, can you give me some hints on grabbing the rotation fo the player from the current tranform to send to the server?

thanks!

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #19 - Posted 2003-01-18 17:24:37 »

Okay here is how you do it. Take 2 pieces of paper. Lay one of them flat on the desk. This is the plane that your players are on. Next take the second page and put it perpendicular to that one. This is the plane that you want to take your angles from. Look down on the two pages. Take the bottom left corner and measure your angles from this corner. Objects are either heading towards or away from this plane.

Does that help any? If it doesn;t I'll try and get some vector art together for ya (hard to draw with HTML).


http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #20 - Posted 2003-01-18 17:26:26 »

Note, if its getting harder to conceptualize - then we can go full3D. We'll move more data, but for our purposes that's not really the point.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #21 - Posted 2003-01-21 11:48:40 »

ok, I have the server and client running.  I have fired up 2 clients at once and can see the "other" moving around.  Using x and z I am able to see full 2D movement...turns, moving straight, etc.  Not rotating yet, work on that today.

So far though, I am happy with what I see.

M

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #22 - Posted 2003-01-21 16:28:48 »

Good Smiley Lemme know when you have some more questions.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #23 - Posted 2003-01-21 17:34:44 »

ok, got player rotation working...in a round about way.

I found if I get the Matrix of the current transfrom on the client and get the heading(found math on net) and send that as the rotation as a double then apply it as a rotY(heading) when the other clients recieve it....

1  
2  
3  
4  
5  
Transform3D toSend = new Transform3D();      
Matrix3d m = new Matrix3d();
toSend.get(m);

double heading =  Math.asin(-m.m02)


it seems to work... not sure if its correct, but the clients look ok.

more later...

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #24 - Posted 2003-01-21 19:28:55 »

ooops nevermind....lol

this works as long as you are facing forward.  WHn you turn past your perpidiclar plane, you shoot behind yourself

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #25 - Posted 2003-01-24 13:25:22 »

Angle issue resolved(hopefully).

On to 'Projectile hits player' scenarios...

Obviously the server should deicide when someone is "hit" to limit hacker intervention.  The server, in it's current form knows the following about the player:
x, y, z, rotation in raw data.

about the projectile:
x,y,z, rotation in thr form of a Transform3D. This transform is updated per server click for the life of the projectile.

Should I create transform groups for both Player and Proj and do statndard collision detection with a behavior on the server, or is there a simpler 'intersects' method I am not aware of , or a better solution...?

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #26 - Posted 2003-01-24 18:02:21 »

Well you're headed in the right direction with having the server solve the interaction. Here is where things start to get tricky. Each player has their copy of the 'world' and the server has its copy of the 'world' - which overrides theirs.

So lets start with a little bit of theory. If all traffic is flowing through the server, then the player is updating his position based off what the server says his position,stats, etc is - not what he thinks it is.

So lets look at what this means:

* every frame I'm sending my information to the server
* every frame (in the best possible case) the server will tell me where I am and I will move there.
* every frame I will tell the server about projectiles I have fired
* every frame the server will tell me about where *all* of the projectiles are in the world

So as you can see, this is where the server stops being a traffic cop, and starts being the world moderator. This is also where we have our first code change (remember we're doing this in stages - I want you to understand why we're doing things). The player is now only responsible for sending his positional information every frame (not the state of the world). The player is also responsible for telling the server when he wants to make a change to the world.

This solves two problems. First, it gives the server to mediate disagreements between the clients - because the only real world view is the servers world view "say whatever you want, but my judgement is law". Second it makes it a lot harder to cheat (not impossible) because the server is the one making all the decisions.

There are some downsides to this, but we will come to those soon enough Smiley

So, the player doesn't change from the perspective of what it receives (its still going to receive a world state packet telling it where everything is and its facing, etc). But now it further limits what it sends every frame as every thing that the player wants to do is now a transaction to the server. "hey server I am moving to position blah.blah". The player can then in its client move to that position with the expectation that the servers response will not be a veto of that move - so long as to the world that move is in truth valid.

So here we go:

A: move 1,1,90deg
B: move 2,1,20deg
server: (a:1,1,90;b:2,1,20) -> clients A,B
A: move 2,10,90deg
B: move 2,5,30deg + projectile 2,6,12deg
server: (a:2,10,90;b:2,5,30;p1:2,6,12)

Does that make sense so far?

Now here is where we get to the crux of online gaming (and one we won't solve for some time yet) - latency. In our game it is likely that over a LAN the response from the server will happen fast enough that the clients and server can move in lock step fashion ... but over the internet.... hell would freeze over first.

But lets go ahead and implement this client server movement/shooting strategy and then proceed from there.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #27 - Posted 2003-01-26 21:46:30 »

just a short clarification.  The client is handling his own move with a behavior(wakeUpOnFrame(0) then does transform to transformgroup, then sends results to server) and sending that move to the server, who sends everyone moves out.  Should I also be handling the clients move by what the server sends back(this is prior to the code change you are talking about at the end of your post)?


MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #28 - Posted 2003-01-27 17:29:29 »

Sorry to take so long to respond. News world has been very busy of late.


Yes, the client would handle its own moves and the server would in the average case simply be validating that move. What happens in high latency environments what you will see is that you will do a lot of moving and then the server will pop you back to the last location that it computed for you. The worse the latency, the worse the popping. This is a factor in all online games (especially MMORPGs where the server has a lot of work to do).

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #29 - Posted 2003-01-27 19:46:20 »

ok, Ill switch my code back so my movement behavior is setting my local move for the players transform group and send that location to the server.  Since I am using wakeup on frame(0) and the server is sending updates every 30 ms to all players, should I put a 30ms delay in the framerate?  So they are attempting to be on the same page?

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

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

The first screenshot will be displayed as a thumbnail.

ctomni231 (36 views)
2014-07-18 06:55:21

Zero Volt (34 views)
2014-07-17 23:47:54

danieldean (27 views)
2014-07-17 23:41:23

MustardPeter (30 views)
2014-07-16 23:30:00

Cero (44 views)
2014-07-16 00:42:17

Riven (46 views)
2014-07-14 18:02:53

OpenGLShaders (35 views)
2014-07-14 16:23:47

Riven (35 views)
2014-07-14 11:51:35

quew8 (31 views)
2014-07-13 13:57:52

SHC (67 views)
2014-07-12 17:50:04
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!