Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (516)
Games in Android Showcase (122)
games submitted by our members
Games in WIP (577)
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  
  An AI challenge  (Read 12851 times)
0 Members and 1 Guest are viewing this topic.
Online SimonH
« Posted 2008-07-06 03:19:26 »

The Scenario;
A bot is released in a viable location on an unknown map (but of a known size).
The bot must locate and visit five randomly located targets as quickly as possible.
The bot has can cast sight-rays but has no more information than that.
The map is full of large, mobile obstacles.

The Question;
What is the best way to achieve this?

I've set up the experiment with random bots here (targets are yellow dots).

I've a couple of ideas myself (click on 'show debug data' for hints) but I wonder what other approaches there might be?

People make games and games make people
Offline DzzD
« Reply #1 - Posted 2008-07-06 14:05:55 »

provide an interface and a test space so that we can do our own robot

first idea would be to use a 2d array.
each step will throw a ray  in the direction of the most unknow surface direction (using the 2d array to find this direction) and will update the 2d array, then a path finder will help in exploring the whole surface.

does the robot know the difference between a wall and a moving object ?

Offline Abuse

JGO Knight


Medals: 13


falling into the abyss of reality


« Reply #2 - Posted 2008-07-06 14:30:48 »

Yeah Simon, do it - sounds like fun!  Grin

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online SimonH
« Reply #3 - Posted 2008-07-06 14:36:12 »

does the robot know the difference between a wall and a moving object ?
No! That's what makes this so tricky!

The full source code is here. It should compile ok... Roll Eyes

Look at src/RandomAI.java for implementation instructions.
VectorAI.java, GridAI.java and FuzzyAI.java also give example code (I'd ignore the other *AI.java files for now).
If you post/send AI code I can add it to the webpage for all to see - showing-off encouraged!

It's all a bit scrappy - it wasn't really intended for distribution - but I hope its reasonably clear.

People make games and games make people
Offline DzzD
« Reply #4 - Posted 2008-07-07 01:21:40 »

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  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
...
...

src\MyAppletStub.java:7: <identifier> expected
  private Hashtable<String,String> _properties;
                   ^
src\MyAppletStub.java:26: '(' or '[' expected
    _properties = new Hashtable<String,String>();
                               ^
src\Player.java:111: <identifier> expected
        public Vector<Player> visibleEnemies=new Vector<Player>();
                     ^
src\Player.java:112: <identifier> expected
        public Vector<Player> visibleFriends=new Vector<Player>();
                     ^
src\Player.java:113: <identifier> expected
        public Vector<Waymark> visibleTargets=new Vector<Waymark>();
                     ^
src\Player.java:115: <identifier> expected
        public Vector<Waymark> visitedTargets=new Vector<Waymark>();
                     ^
src\Player.java:415: '(' or '[' expected
                Vector<String> keywords=new Vector<String>();
                                                  ^
src\PlayerManager.java:13: <identifier> expected
        public Vector<Player> players=new Vector<Player>();
                     ^
src\PlayerManager.java:146: '(' or '[' expected
        Vector<Player> tempPlayers=new Vector<Player>();
                                             ^
src\PlayerManager.java:147: '(' or '[' expected
        Vector<Player> shuffledPlayers=new Vector<Player>();
                                                 ^
src\PlayerManager.java:275: '(' or '[' expected
        Vector<Player> tempPlayers=new Vector<Player>();
                                             ^
src\PlayerManager.java:276: '(' or '[' expected
        Vector<Player> shuffledPlayers=new Vector<Player>();
                                                 ^
src\VectorAI.java:94: <identifier> expected
        Vector<Point> points=new Vector<Point>();
...
...


cant compil due to <...> syntaxe

Offline irrisor

Junior Duke





« Reply #5 - Posted 2008-07-07 07:46:54 »

cant compil due to <...> syntaxe
erm, use java 5 language level then!
Online SimonH
« Reply #6 - Posted 2008-07-07 17:33:04 »

cant compile due to <...> syntax

Um, sorry! Should have said it was Java 5+

People make games and games make people
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #7 - Posted 2008-07-09 03:35:34 »

I'd say divide the portion of the map that the bot can see using a quad tree into increasingly smaller grid segments. Then when they are of a certain size, use A* to find the best path at a certain time step. Because objects are moving, reevaluate the path every time step.

Then when the goal is out of the sight range, use a point that is closest by Euclidean (or Manhattan) distance to represent waypoint.

On top of that, each bot needs to have a memory, so that if the closest point leads into a dead end or something, it will know not to try that location again.

So, in the end, you need:

- A 2D array of booleans representing the entire map - visited or not visited.
- A temporary 2D array representing the bot's current vision.
- Find the point within the temporary array that is closest to the goal and hasn't been visited.
- Solve the path to that point using A*.

That should work, and won't be too costly.

See my work:
OTC Software
Online SimonH
« Reply #8 - Posted 2008-07-09 17:08:38 »

Latest version here (source here) with shiny new bot: AStarAI!

@Demonpants

That's pretty close to what I've done, but no quad tree and the grid is ints and indicates 'visitedness' - the lower the value the less that square has been seen and the further away it was when it was seen (this is cheap to do as I can use the g values from the A* search).

I've time-sliced the A* because (did I forget to say?) the idea is to get each game turn done in <=2ms...

AStarAI looks for targets and if it finds one it tries to path to it. If it can it goes there, if not it looks for the least visited square it can see and goes there. If it sees a new target it immediately repaths to try and reach it. There's a bit of fuzzy logic obstacle avoidance thrown in to stop the bot getting stuck on corners. It uses full A* each time (to find the shortest path).

This strategy works but it doesn't look very 'natural' though; if you turn off the debug data it's hard to work out what the bot is up to...
It's pretty rubbish on the maze map too.  Sad

Next experiment: partial AI (first path found).



People make games and games make people
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #9 - Posted 2008-07-09 22:49:54 »

Oh, very cool.

Maybe you could try a Q Learner or a neural net? Could be fun.  Grin

See my work:
OTC Software
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online SimonH
« Reply #10 - Posted 2008-07-10 13:58:46 »

New Bots added: PartialAStarAI & NoAI + a new circular map. Applet here, source here.

Maybe you could try a Q Learner or a neural net? Could be fun.  Grin

They'd both work ok, trouble is that they're both evolutionary-type methods so they need a learning phase. The idea of these experiments is to 'get it right first time, and fast'. It's like looking for casualties after an air crash in unknown terrain; no second chances...

What I'd really like is alternatives to grid-based methods - maybe using vectors or point-source influence maps or something...

Anyone got any suggestions?


People make games and games make people
Offline Jackal von ÖRF

Junior Duke





« Reply #11 - Posted 2008-07-10 21:13:33 »

The AStarAI and PartialAStarAI seem to spend too much time in going to places where there is nothing new to see.

I think it would be a good strategy to locate the walls and move to areas from which you can see places which you have not yet seen. Something like this:

Each grid cell has one of three states: UNKNOWN, EMPTY, WALL (let's assume that the bot can tell the difference between a wall and a moving obstacle - for example by measuring the distance to the obstacle twise and checking whether it moved or not). In the beginning all cells are UNKNOWN, except that the bot's startup location is EMPTY. When the bot sees a cell, it is marked WALL or EMPTY depending on whether there is a non-movable wall or not.

The bot will locate the closest UNKNOWN cell which is next to an EMPTY cell - let's call this cell X. Then the bot will locate the closest EMPTY cell from which it can see X - let's call this cell Y. (Or even better, locate the closest EMPTY cell from which you can see any UNKNOWN cell.) Then the bot will move to Y and look in the direction of X as far as possible. As a result, X and the UNKNOWN cells around it are marked EMPTY or WALL. Repeat.

If the bot sees a target, reaching this target may or may not take priority over looking at UNKNOWN cells. It might be smart to look at UNKNOWN cells which can be seen when moving along the path to the target. For example, if the target is straight ahead, instead of moving directly to the target, stop a couple of times to look left or right (or take a detour) if there are UNKNOWN cells nearby. Of course, if you know that it is the last available target, then there is no need to look any further.

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #12 - Posted 2008-07-12 19:42:01 »


They'd both work ok, trouble is that they're both evolutionary-type methods so they need a learning phase. The idea of these experiments is to 'get it right first time, and fast'. It's like looking for casualties after an air crash in unknown terrain; no second chances...


Well, basically you would teach them and then write the resulting "brain" to an AI file. A typical Q Learner brain for that case will be only like 100kb at the most.

See my work:
OTC Software
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 823
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #13 - Posted 2008-07-14 14:10:51 »

The Scenario;
...
The bot has can cast sight-rays but has no more information than that
...

Anyone got any suggestions?


Aren't you cheating here? You're looking around corners for flags, when the AI already visited that spot. In reality it might remember whether grids where accessible, but it can't really see whether there is a flag around the corner... It would actually analyze the environment, and walk a bit to truely look around the corner, which would require quite a lot of intelligence.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Online SimonH
« Reply #14 - Posted 2008-07-14 14:29:44 »

Well, basically you would teach them and then write the resulting "brain" to an AI file. A typical Q Learner brain for that case will be only like 100kb at the most.
Would this work even on entirely new maps, I wonder? I suppose it might...

Aren't you cheating here? You're looking around corners for flags, when the AI already visited that spot.
Not sure what you mean - bots can only see in straight lines...

It would actually analyze the environment, and walk a bit to truely look around the corner, which would require quite a lot of intelligence.
That's the challenge! I want bots that do the least work for the most effect. I'm currently looking at 'frontier-based exploration' which is used by robots, but it's not ideal for use with mobile obstacles...


People make games and games make people
Offline Jackal von ÖRF

Junior Duke





« Reply #15 - Posted 2008-07-15 23:52:23 »

I implemented a bot using the strategy which I described in my previous post. It still has some problems in getting stuck easily, especially in the roundmaze level, but in other levels it beats the other bots clearly. Here is one test run:

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  
- forest:

mapsize=800,880
config loaded - 4 reds and 0 blues
JackalsAI done 497 turns 30878ms
NoAI done 1019 turns 833ms
PartialAStarAI done 1063 turns 3699ms
AStarAI done 2003 turns 22724ms

- maze:

mapsize=800,759
config loaded - 3 reds and 0 blues
JackalsAI done 657 turns 10064ms
AStarAI done 5400 turns 14515ms
PartialAStarAI done 11473 turns 15299ms

- square:

mapsize=800,800
config loaded - 4 reds and 0 blues
JackalsAI done 304 turns 17811ms
PartialAStarAI done 493 turns 2640ms
NoAI done 1048 turns 633ms
AStarAI done 1490 turns 20162ms


Right now the bot's sources are 905 SLOC and its tests are 593 SLOC. You can get the sources and compile/run them from http://www.orfjackal.net/temp/fow_orfjackal_2008-06-17.zip


P.S. You should reorganize the design of the simulator. Now the bots have free access to all information about the game world (especially through the FOW object and its fields such as "public Vector<Waymark> targets"). You should give the AIs only a very restricted interface through which to communicate. I wasn't sure what was allowed (because nothing was prevented), so I used only those methods/fields which were mentioned in RandomAI and created a wrapper for accessing only those (JackalsAI.PlayerSensors).

Online SimonH
« Reply #16 - Posted 2008-07-16 15:42:47 »

I am impressed - now that's showing off! (I've added your AI to the simulator). Officially the best AI yet...

the bots have free access to all information about the game world
The simulator is meant to be as flexible as possible for different scenarios (hence all the public code). Anyway, what would cheating prove? No glory in that...

It still has some problems in getting stuck easily
I've added a (primitive) fuzzy navigaton method to the Player class (fuzzyNavigate()) which you could use locally to smooth the sticking a bit...


People make games and games make people
Offline Jackal von ÖRF

Junior Duke





« Reply #17 - Posted 2008-07-16 19:49:52 »

I added today some simple collision detection - if last move failed (apparently because of hitting a wall) then strafe randomly left/right or rotate to random direction. With the help of that the bot can finish roundmaze in a new record time. But it still sometimes gets stuck because of changing the target (unseen cell) too rapidly (the bot will rapidly try to move into two opposite directions). It's also quite a CPU hog. For example it finds the closest target (with breadth-first search) and calculates the path to it (with A*) on every step, which causes visible slow frame rate when the target is far away.

Next I'll improve the movement, add target priority management and do some profiling in order to optimize the worst bottlenecks. I'll release a new version of the bot when I get these done.

The simulator is meant to be as flexible as possible for different scenarios (hence all the public code).

Then you could provide a different set of interfaces for different scenarios. For example one interface has those methods which tell only what the bot itself can see. Then another interface tells information about the whole map's structure. Again another tells the exact locations of all targets and enemies etc.

You could improve the framework code by having an interface which all bots need to implement. Now you are needlessly using reflection in Player.reloadAI() to call the gameTurn() and other bot methods, which is very error prone. Also please move all classes away from the default package. It's not possible to refer to classes in the default package from any other package (this was one of the reasons why I created a wrapper for the Player object in my code).

Offline timfoden

Junior Duke


Projects: 2



« Reply #18 - Posted 2008-07-17 14:48:35 »

Hi Simon,

I'm afraid I can't resist challenges like these  Smiley My bot is just one file (TimsAI.java).  The algorithm is pretty much the same as the one outlined by Jackal.  But my bot is generally slightly slower to get to a solution.  There are still a few bugs and inefficiencies, but here it is, warts and all.

Perhaps I'll even get around to improving it a bit.

I've added a (primitive) fuzzy navigaton method to the Player class (fuzzyNavigate()) which you could use locally to smooth the sticking a bit...

Cool.  I'd was already using your fuzzyNavigation code, this just makes it easier!  Smiley

Cheers, Tim.

Try Pipe Extreme -- can you get to the end of the pipe?
Online SimonH
« Reply #19 - Posted 2008-07-17 15:14:37 »

Cool! TimsAI looks pretty smart - that fuzzy avoidance gives it the edge...

I've updated the source and put it in the package edu.sph.fow (sheer laziness before!).
I've also added a build.xml file so you can compile using ANT if you have it...
These 2 changes should mean that you can use your own packages more easily.

Please remember though I have to check the code for malware by hand and I won't bother if there's hundreds of files (no jars accepted - java files only). Also could people compile to java 5 as a standard? Not all JREs are 6 yet.

Oo! This is getting exciting now! I have my own cunning plan which should be a killer - watch this space!

EDIT: Forgot to say there's now also a global config.txt file to save having to modify the individual map config files.

People make games and games make people
Offline timfoden

Junior Duke


Projects: 2



« Reply #20 - Posted 2008-07-17 16:53:31 »

Quote from: DzzD link=topic=18902.msg148927#msg148927
does the robot know the difference between a wall and a moving object ?
No! That's what makes this so tricky!

And then some!  In fact I think that both Jackal and I have cheated somewhat in this regard.  In my bot I check that walls are still walls on a periodic basis.  This applies to walls that my bot can't currently see... it's working from it's memory of what walls it found before.  Jackal's bot additionally appears to check for walls in places the bot has never seen.

Both of these procedures make it easier to write the robot.

If we couldn't do this, then if the robot runs out of places to look for targets, it'd have to go round and look at all  the walls again, perhaps for a long time, before finding one that has moved.

So Simon, what's your feeling about doing this kind of wall checking... is it allowed?  Smiley

Of course we can't find the targets with this kind of method.  The robots have still got to go around an look at all the possible places they could be.

Cheers, Tim.

Try Pipe Extreme -- can you get to the end of the pipe?
Online SimonH
« Reply #21 - Posted 2008-07-17 17:16:41 »

So Simon, what's your feeling about doing this kind of wall checking... is it allowed?

Um, No. Tongue The bots should only use data that they've actually collected from observation - as if they were humans put in the maze for the first time. You should assume that your ONLY sources of new data are from lineOfSight() and visibleTargets. What you haven't actually seen you can't know about... I said it was tricky!

BTW can anyone suggest a good single-figure scoring system? The best bots should have the lowest turns and the lowest CPU usage - what's a good way of combining these numbers to give an overall 'fitness' score?

People make games and games make people
Offline timfoden

Junior Duke


Projects: 2



« Reply #22 - Posted 2008-07-17 17:54:43 »

Um, No. Tongue The bots should only use data that they've actually collected from observation - as if they were humans put in the maze for the first time. You should assume that your ONLY sources of new data are from lineOfSight() and visibleTargets. What you haven't actually seen you can't know about... I said it was tricky!

1.  My bot only ADDs walls by observation.  It's only the removal of SOME walls it does "by ESP" Smiley  So it's not so bad.
2.  lineOfSight unfortunately takes 2 points as parameters.  So just specifying that lineOfSight should be used does not restrict the robot from testing any points, even if it can't see them.  I agree with Jackal in this regard... an interface that only allows the operations that are considered legal would help to produce bots that abide by the rules.  Smiley
3.  You can remove this "cheat" functionality from TimsAI by deleting the if statement that begins like this: if( parent.gameTurn % PERIOD_OBJECTS == 0.  TimsAI still works without this, but it's no longer guaranteed to find all the targets.  It requires a whole extra strategy to deal with this situation.

Cheers, Tim.

Try Pipe Extreme -- can you get to the end of the pipe?
Online SimonH
« Reply #23 - Posted 2008-07-17 18:37:29 »

OK, point taken!  I've added 3 new methods to Player (new source);

int castRay(x,y) - returns distance from bot to nearest wall or to x,y if no wall hit
int castRay(dir) - returns distance from bot to nearest wall in direction dir
boolean canSee(x,y) - returns true if x,y is visible to bot

So now instead of parent.lineOfSight(player.x,player.y,x,y) you can now use player.castRay(x,y).

These are now the only calls that a bot can legally use...


People make games and games make people
Offline timfoden

Junior Duke


Projects: 2



« Reply #24 - Posted 2008-07-18 10:09:49 »

OK, point taken!  I've added 3 new methods to Player (new source);

Erm... the source isn't in the .jar file... it's in the .zip file: fow.zip)

int castRay(x,y) - returns distance from bot to nearest wall or to x,y if no wall hit
int castRay(dir) - returns distance from bot to nearest wall in direction dir
boolean canSee(x,y) - returns true if x,y is visible to bot

These are now the only calls that a bot can legally use...

Thanks for that.  It certainly makes it a lot clearer.  Smiley

However.... (you knew that there was a however didn't you? Smiley )

(1)
These calls don't restrict their ability to see to the direction the bot is facing.  Is this what you intended?

(2)
Being restricted to only these calls for sensing makes it extremely difficult to create any kind of grid where it's possible to test the emptiness, or otherwise, or a grid cell with exactitude (i.e. to repeatedly get the same answer, even if the bot has moved somewhere else but can still "see" the cell).

I've spent quite some time trying to come up with a reliable method for this, but so far I've failed.  For any test I've come up with so far to define walls (the ones that never move), I haven't been able to prove consistently that the cell is still occupied.

So eventually I thought... hold on, Simon's AStar based bots define a grid... what do they do?

... and I find that they test emptiness by making calls to parent.canMoveTo(x,y); -- so is this allowed?   Wink

UPDATE: OK, I've got a modified version of my bot (TimsAI.java) that ONLY uses the functions specified for it's sensing of the environment.  It doesn't use parent.canMoveTo(x,y).  It still manages to finish most of the time, but it's efficiency is hampered by it's inability to be certain about the status of the walls.   Undecided  I think I've now figured out a method to do wall sensing a bit more accurately (a verification scheme -- but still not 100%), but it'd be a lot easier just to use parent.canMoveTo()!

Cheers, Tim.


Try Pipe Extreme -- can you get to the end of the pipe?
Online SimonH
« Reply #25 - Posted 2008-07-18 15:15:08 »

(0) it's in the .zip file: D'oh!

(1) I originally intended the bots to stick to their FOVs but on considration changed it. It seems fair to allow a bot to look in any direction and move all in one turn. Rabbits have near 360' vision...

(2) Hmm.... This is a close call - The purist in me is saying 'No, only rays can be used!' but the idle git in me is saying 'aw, come on! if you can see the centre of a square then it's OK to canMoveTo() the corners!'
*reflective pause*
I think no canMoveTo(). It's up to the bots to refine their knowledge (maybe do a single ray on distant squares and a multi-ray on closer squares?). You can tell if a bot is stuck if player.lastMoveSuceeded==false.
I've modified the AStarAIs so they do a canSee() on the 4 corners and centre of each square - seems to work ok...

I've now updated the simulator and I've added a 'solo' option for switching off the other bots during testing.

People make games and games make people
Offline timfoden

Junior Duke


Projects: 2



« Reply #26 - Posted 2008-07-19 15:46:49 »

Quote from: SimonH link=topic=18902.msg149437#msg149437
(2) I've now updated the simulator and I've added a 'solo' option for switching off the other bots during testing.

The current fow.zip doesn't seem to contain the source for these changes.... Smiley


Theres now an updated TimsAI.java


On a separate note, I think I've spotted a couple of minor bugs in your Bresenham (not Bresham) line algorithm code (in FOW.java).  These bugs show up in both the canSeeBetween and lineOfSight functions.

(1) The horizontal code says "if (error > dx)" when it should say "if (error >= dx)".  This results in horizontal lines not doing the last Y coord increment (in combination with the error=0 discussed below).

(2) The error component is normally initialised to half of its full range (rather than 0).  This is so that the line is as symmetrical as possible, instead of lop-sided.  Need to take care with this as you've got the vertical parts subtracting from the error instead of adding.

Cheers, Tim.

Try Pipe Extreme -- can you get to the end of the pipe?
Online SimonH
« Reply #27 - Posted 2008-07-19 16:23:37 »

Latest version here (source here).

New map added.

On a separate note, I think I've spotted a couple of minor bugs in your Bresenham (not Bresham) line algorithm code (in FOW.java).  These bugs show up in both the canSeeBetween and lineOfSight functions.
Oops! That'll teach me to 'borrow' code! Can you tidy it up for me Tim?

People make games and games make people
Offline Jackal von ÖRF

Junior Duke





« Reply #28 - Posted 2008-07-19 19:05:52 »

Here is my bot's latest version: http://www.orfjackal.net/temp/fow_orfjackal_2008-06-19.zip

It still relies on canMoveTo as I did not yet have time to change it. I'll change it to castRay when I have more time.

Online SimonH
« Reply #29 - Posted 2008-07-19 23:20:50 »

Here is my bot's latest version: http://www.orfjackal.net/temp/fow_orfjackal_2008-06-19.zip

It still relies on canMoveTo as I did not yet have time to change it. I'll change it to castRay when I have more time.
Cool. I've added it in.
It looks really smooth but it eats CPU - on the openspace map the average peaked at 100ms per turn on my machine!

People make games and games make people
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.

TehJavaDev (31 views)
2014-10-27 03:28:38

TehJavaDev (26 views)
2014-10-27 03:27:51

DarkCart (40 views)
2014-10-26 19:37:11

Luminem (21 views)
2014-10-26 10:17:50

Luminem (26 views)
2014-10-26 10:14:04

theagentd (32 views)
2014-10-25 15:46:29

Longarmx (61 views)
2014-10-17 03:59:02

Norakomi (57 views)
2014-10-16 15:22:06

Norakomi (46 views)
2014-10-16 15:20:20

lcass (43 views)
2014-10-15 16:18:58
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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!