Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
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  
  Good modeling/UML tool?  (Read 5025 times)
0 Members and 1 Guest are viewing this topic.
Offline Preston

Senior Member


Medals: 4



« Posted 2003-08-20 07:12:26 »

There's an older thread on this topic but it didn't lead to any real commendation. Did it?

Is there a good free modeling generator & editor available? It should be able to generate UML class diagrams from an existing source code project.

How do you developers out there manage this task? Usually you start to model some diagrams, then at some point you start to program, but forget to update the diagrams, and later on you see: oh well, 100 classes have been changed, and it takes ages to update the diagrams. :-(

So far I've worked with the following two free ones (the paradigm one provides a free community edition which lacks some functions) :
http://argouml.tigris.org/ and http://www.visual-paradigm.com/

Altough both look good, they don't help me much, rather I feel it hinders me: at one point, when there are enough classes with connections, the whole sheet looks like "missile defense" in level 100 - lines all over the sheet etc. :-)  The connector points jump around the class like mad when you take one class and move it around, etc.
Unbelievable. Am I just too silly to use these "tools" or are they ... all "difficult to use" ?

I think I've to use pen & paper. BUT it's 2003. So do I really have to do this? Oh dear.
Offline kevglass

JGO Kernel


Medals: 164
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2003-08-20 07:24:40 »

I think it depends on what you use UML for. Personally, I use it as a structuring aid while designing (e.g. it help me think clearly) and as a tool to communicate ideas to other developers before we start coding or early on.

From personal experience, UML isn't that great as a tool after development for potentionally teaching new comers how the system works, JavaDoc + a really good architecture document does a better job.

Free UML tools are rare, good free UML tools are rarer. I'd recommend the simple tool I started writing, but its not really aimed at doing reverse engineering.

I think you've found the two that are actually in any form complete and have free editions. Although I've tried them both and the interface alone puts me off.

I'm really glad you started this topic again,

Kev

Offline dsellars

Junior Member




Need to write more games


« Reply #2 - Posted 2003-08-20 07:43:36 »

I think the problem is that there really isn't that much out there (that I have seen).  Even the ones you have to pay (alot of money) for have their problems.

I would reccomend having a look at Kev's UML editor.  It is good for structureing ideas, it's simple and easy to pick up.  But as he said it's not really aimed at reverse engineering though.

As I posted in another thread there is a tool for taking digital pictures of a white board and changing them to simple diagrams which seems a good idea to me.  But it's not really useful for home/hobbiest development, and it is quite costly Sad

Does any one else have any reccomendations/favorties?  it seems to be quite an important aspect of design and is so unsuported.

regards,

Dan.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline troggan

Junior Member




no guts no glory


« Reply #3 - Posted 2003-08-20 09:10:21 »

I use arouml (http://argouml.tigris.org/). it's under the bsd license, but it's not easy for a beginner Sad.

(http://www.wannawork.de) - Will work for food
(http://tvbrowser.org) - Java EPG
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #4 - Posted 2003-08-20 11:53:47 »

Quote
Is there a good free modeling generator & editor available?

No.  No matter how much you spend IMHO there are no good UML tools available.  Well maybe pencil and paper.. that's the best so far.

Offline Preston

Senior Member


Medals: 4



« Reply #5 - Posted 2003-08-20 13:49:31 »

Well thanks for your answers.

I feared it and now you say it...
:-)
Offline Rob Grzywinski

Junior Member




Reality Interactive


« Reply #6 - Posted 2003-08-24 04:43:56 »

I have used:

  http://www.eclipseuml.com

on a number of occasions with great degrees of success.  It uses EMF (http://www.eclipse.org/emf) to perform code generation and it uses an XMI repository (which is just dandy for conversions to other formats or enhanced code generation).
Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #7 - Posted 2003-08-24 12:08:13 »

Not to turn this into another religious war, but I'm very sceptical about using UML for code generation.
UML is very good for discussing code design with other programmers, as it lets you quickly scetch the design on a piece of paper or a whiteboard.. but the whole "gui-drag-windows-to-make-classes" approach of programming really bothers me. I believe the class relations should evolve over time from a bottom-up type design with constant refactoring.
If you spend a month designing everything before starting to implement it, the early showstoppers are going to rip the project apart and make management say nasty things.


Uh, sorry about the rant. Wink

Play Minecraft!
Offline shareme

Junior Member




Java games rock!


« Reply #8 - Posted 2003-08-24 12:12:50 »

I do not use UML as code generation tool as of yet..I will be doing that once I have finished my J2ME 2D GameFramework library..

But the one UML tool I have picked up and it has a free community edition is Posiedon from Gentleware.com

Its based on Argos..

Its not integrated with eclipse as of yet however.. I use  via webstart..


Offline Rob Grzywinski

Junior Member




Reality Interactive


« Reply #9 - Posted 2003-08-24 14:54:08 »

Since it appears that Markus_Persson was aiming his rant in my direction I will footnote my statement slightly.

UML != class diagrams.  This is a common misconception.

If I draw a state chart for example, what good is it to code it?  I'm going to make 1000 mistakes and at the end of the day the usefulness of the UML is moot.  Sure, I was able to visualize the structure but the whole point is to end up with code that produces some known result.  So I use the state chart to generate the code in the same way that I use yacc to generate a parser (which is nothing more than an FSM).  Not only does the generation guarantee me a result, I do not have the document legacy issue that is common with UML (i.e.  the documents lag the implementation).

This same argument can be made for sequence diagrams, etc.

As for the common case, class diagrams, Eclipse UML does something that really no other UML editor has done before (yes, this is obviously my opinion):  the diagram is the code and the code is the diagram.  If you've looked under the covers of Eclipse and the AST you realize that Eclipse (specifically the JDT) isn't just a glorified text editor;  it acutally understands the structure of the code.  The first time that you have an Eclipse UML window open and type "public class Blah" in your editor and a picture automatically appears in the window you think:  OMG this is the way that it should be.  And when you drop a class picture on to your diagram and the class appears in the editor you say something religious.  No more documentation legacy issues.  No more "did I code this to the UML" issues.  The UML becomes part of your development just as a view of the class members or a type hierarchy have become part of development:  just different ways of presenting the code to you visually.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #10 - Posted 2003-08-24 15:36:04 »

When I tried Eclipse UML, code changes, e.g. a simple refactoring, did not update the diagram.  That instantly rendered the diagram useless.
Am I missing something, or do you really have to manually regenerate the diagrams after every modification of the code?

Offline kevglass

JGO Kernel


Medals: 164
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #11 - Posted 2003-08-24 15:39:39 »

Quote

As for the common case, class diagrams, Eclipse UML does something that really no other UML editor has done before (yes, this is obviously my opinion):  the diagram is the code and the code is the diagram.  If you've looked under the covers of Eclipse and the AST you realize that Eclipse (specifically the JDT) isn't just a glorified text editor;  it acutally understands the structure of the code.  The first time that you have an Eclipse UML window open and type "public class Blah" in your editor and a picture automatically appears in the window you think:  OMG this is the way that it should be.


TogetherJ has been doing this for years, and causing this same debate. It always seems to come down to opinion. Mine sticks me on Markus' side.

Generating code from UML tends you towards thinking at too low a level during design stages. "If I just change that in mine design, the code will come out 'right'".

Maybe I'm just repeating my post above, oops, sorry..

Kev

Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #12 - Posted 2003-08-24 16:21:56 »

Quote
Since it appears that Markus_Persson was aiming his rant in my direction I will footnote my statement slightly.


I wasn't aiming it at you at all. I triggered mostly on the topic line, actually. =)

Play Minecraft!
Offline Rob Grzywinski

Junior Member




Reality Interactive


« Reply #13 - Posted 2003-08-24 16:31:14 »

kevglass, don't take this the wrong way, but step outside the box for a moment:

Perform your design phase using UML or rocks and sticks in sand -- just make sure that you are performing a design phase.  I don't think that we're in disagreement here.

Now, use something like Eclipse UML to generate you a diagram as you work and use the UML editor to facilitate writing code.  Why should I go through the process of laying out all of the accessor methods, etc that I already know I need from the design phase in code form when I can do it 10x faster in a diagram?  (yes, we start another thread about how fast you type and how slow UI's are for "coding" Cheesy) Ditto for the object structure.  Ditto for the object relations.  (Or, heck, just use the UML that you already have to create this *inital* structure for you.)  Finish up your code using the synchronized UML view as a tool, just like a members view or a type hierarchy, to show you a more compact representation of the code.

Now the code is complete.  Normally you use a set of unit tests and the whatnot to validate your code against the requirements.  But lookie here!  You have another validation technique!  You hand the UML that was produced as you worked and the UML from the design phase to someone else and ask "Do these two look the same?".  (Yes, that's an oversimplification.  Flame me for my use of smilies and not that.)

And yes, Rational, TogetherJ, etc have all had UML ditties that spat out whatever you wanted.  The point that I was making is that Eclipse UML is really going the other way; you have an IDE that you're already working in and it added another view (again, just like a type hierarchy or a members list) of the code.  I knew when I wrote that statement that it would be commented on which is why I explicitly stated that it was an opinion.  We can debate opinions until the cows come home or just read the threads in which others have already said all that can be said on the topic.  I retract my statement so that we can get back to the topic at hand.

Can we get some comments on the non-canonical UML case of class diagrams?
Offline Rob Grzywinski

Junior Member




Reality Interactive


« Reply #14 - Posted 2003-08-24 16:35:39 »

Let me quicly clarify my last statement to read:

Let's get some comments on the use of code generation in the other UML diagrams (other than class diagrams).
Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #15 - Posted 2003-08-24 16:38:09 »

Quote
kevglass, don't take this the wrong way, but step outside the box for a moment:

Perform your design phase using UML or rocks and sticks in sand -- just make sure that you are performing a design phase.  I don't think that we're in disagreement here.


Actually.. I dislike the idea of the designing the code before implementing it.
Sure, you have to design certain things like external interfaces before getting started, but I'm a firm believer in letting the code design itself through constant rewrites.
It takes about as much time overall, but the code is a lot less sensitive to sudden changes.

And, as we all know, sudden and random changes are not that uncommon. Wink

Play Minecraft!
Offline kevglass

JGO Kernel


Medals: 164
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #16 - Posted 2003-08-24 16:42:36 »

Quote

kevglass, don't take this the wrong way, but step outside the box for a moment:


Stepped Smiley

This medium must be really awful at communicating intention. I wasn't trying to put down your view, honest.

What I meant about TogetherJ, it does it both ways all the time.. UML -> Code -> UML. Infact, its designed to cover the complete lifecycle, iterating over and over. Hence the comparison with what you were saying, about synchronizing both ways.

Coming to the end now, honest. I'm not saying there arn't some great benefits to be had (time saving wise) by using tools that do this type of synchronising. Just that its not always that great since its easy to misuse.

Talking around subjects often helps me learn about things, so debating opinion is quite useful, at least I find it such. Going off topic seems to be a traditional round here Smiley

I agree, we should probably get back on topic, just didn't want you to think there was any negative intention hanging about..

Kev

Offline Rob Grzywinski

Junior Member




Reality Interactive


« Reply #17 - Posted 2003-08-24 16:55:59 »

kevglass:  No negatives taken in any way.  If we didn't all have different opinions then we'd have nothing to learn from eachother.  I "picked on" you as you walked down what I preceived to be a common path and that is that UML should only be used for design.

Markus_Persson:  You actually made me shudder.  You should really rethink your approach to development.  As I tell all of the developers that work for me:  coding (the actual sitting down at the keyboard) is the last step in the process of developement.  You don't hammer away at the keyboard until something you want comes out.  I'll stop here as this is a completely separate thread.  If you want to "go at it" start up another thread and we'll rumble Cheesy

swpalmer:  classes don't immediately show up in the diagram and that's acutally nice as you can add only what you want.  As for the internals of a class, the moment you press save they're all there.  It brings tears to ones eyes.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #18 - Posted 2003-08-24 17:04:31 »

Quote

Markus_Persson:  You actually made me shudder.  You should really rethink your approach to development.


To be fair, often I find you're starting on something totally new and alien, in which case sitting down and designing the whole thing from scratch tends to be impossible. Time like this the best approach seems to be to just jump in and hack out a quick prototype to get a general feel for the problem, and its particular quirks.

Then again, a few use case diagrams typically come in handy when you're in this situation, but i don't really count those as design, more as a list of things to bear in mind.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Rob Grzywinski

Junior Member




Reality Interactive


« Reply #19 - Posted 2003-08-24 17:12:33 »

Orangy Tang:  this is off-topic and we should start a different thread, but protoyping is definitely part of the design process.  Take a look at RUP (the Rational Unified Process) or other such process to give you some background.  Unfortunately, with most programmers the prototypes go directly into production with no other design.
Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #20 - Posted 2003-08-24 17:40:49 »

Quote
Markus_Persson:  You actually made me shudder.  You should really rethink your approach to development.


Well, it's worked for me in the six years I've been coding proffessionally, and the nine years before that.

But, hey, thanks for insulting me!

Play Minecraft!
Offline Rob Grzywinski

Junior Member




Reality Interactive


« Reply #21 - Posted 2003-08-24 17:49:16 »

No problem!  I'm always here to deal out the hate, malice and insult.
Offline Rob Grzywinski

Junior Member




Reality Interactive


« Reply #22 - Posted 2003-08-24 18:33:08 »

So that I don't have to watch my back for someone named Markus_Persson at the next developers conference that I go to, I will make my position clear:

I did not intentionally make an insult to you;  I expressed an opinion.  Had I stated "You don't have a design phase?  Your code must be complete crap" then you could be as pissed off at me and insulted as anyone would be.  If my opinion did in fact insult you I do apologize -- to make it better I will spread insult, anger and malice to everyone else so that it's null'd out.  Everyone else that's reading this:  you SUCK!

In response to you (and I don't mean to insult you any further, but I do wish to express more opinions as I'm full of it ... I mean, them), time does not dictate quality.  I know people that have been developers for 40 years (if swtiches and punch cards can be considered developing Cheesy) that write worse code than my 15 month old god-child who just smacks her hands against the keyboard.  If time was directly equatable to "maturity" then all old people would have reached self-actualization.  We all know that this just isn't true.

To super-duper clarify, I'm not saying that you're in fact not mature in your profession.  I'm simply stating that your argument is not valid.

Why do I bring all of this up?  Well, it's a perfect introduction for the CMM.  Believe what you want about the maturity model and its applicability to the "real world", it still opens ones mind to other possibilities.  Of the gaggles of developers that I know, I would have to say that 95% of them are at and will always be at CMM level 1.  There are other levels people!  (Footnote, even developers that I know that work at companies that are CMM level 3 are, as coders, stuck at CMM level 1.)

For those of you who do not know what a CMM is, take a read of:

 http://www.dfas.mil/technology/pal/cmm/

as an example.  You can get the fully ditty, which is simply facinating reading, but it costs big big big bucks.
Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #23 - Posted 2003-08-24 19:03:25 »

I did not take offence because you disagreed. Everyone (including myself) are filled to the brim with opinions, and I've learned to accept that.

I took offence because you shuddered at my opinion. There's a difference between disagreeing and ridiculing.

Play Minecraft!
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #24 - Posted 2003-08-24 20:36:48 »

Quote
Orangy Tang:  this is off-topic and we should start a different thread, but protoyping is definitely part of the design process.  Take a look at RUP (the Rational Unified Process) or other such process to give you some background.


Whether you count prototyping as a formal stage in itself or just a first stage in the traditional iterative or waterfall cycle is really just arguing over syntax Tongue

I'd look further into the RUP, except i've found most of the Rational tools to be at best annoying, and at worst a real hinderance. They have a tendancy to make me focus on the irrelevant implementation details while i'm just trying to get a basic design down.

Er, to try and avoid going too off topic, I'll concur with the earlier answer that the best tool is pen and paper. I get though reems of the stuff Grin

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Rob Grzywinski

Junior Member




Reality Interactive


« Reply #25 - Posted 2003-08-24 23:03:58 »

Orangy Tang:  Since we're off topic, let's go balls out!  Here's a poignant blurb:

 http://www.rational.com/products/whitepapers/102016.jsp

Markus_Persson:  Again, I apologize.  Let's chalk up my shudder to PTSD from working in the trenches of too many coding shops where I have had to deal with the carnage that was left over from poorly planned and poorly implemented projects.  "An ounce of forethought or design would have never allowed this to happen" I would often scream from my dimly lit basement cublicle as the task master whipped me with the cat o' nine tails.  To this day I still can't walk into a dark S&M shop ...  much to my wife's chagrin.
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #26 - Posted 2003-08-25 03:00:48 »

I haven't coded with a proper design doc for 8 years.
I did it once in university when I was forced to.  After than in the real world I can't get anyone to buy in to the idea, and I'm beginning to believe that it would truly be wasted effort.

Design requirements in the real world, at least with any project I have been on change too fast, or there are design parameters that you just won't have accurate information for until you have already coded a great deal... I can see how this could be scary to some people, but quite frankly I can't see how I could work otherwise.

Now that isn't to say that a lot of design decisions should not be well thought out and considered before coding down the wrong path..  but usually those can be made in an informal meeting with the team.  The teams I've worked with/managed have only been about 5 people or so.  I think a more rigourous, formal design document would be needed for significantly larger teams.

I think one of the ideas of XP - that the code itself is the best design document since it is 100% unambiguous is not unreasonable.

Looks like I need to take another look at the Eclipse UML tool.. although I must say up front that I expect to be disappointed Smiley ...    I will give it a chance though.   I really do want a UML tool that "brings tears to my eyes"  Smiley

Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #27 - Posted 2003-08-25 04:54:40 »

Quote
Markus_Persson:


Don't worry, I was in a very bad mood yesterday. =)

Of course you have to plan. I'm just a big advocate of heavy prototyping and small teams. I make it very clear to my bosses and managers that the first versions they get that early in the projects are just PROTOTYPES, and while they can test them to see if they do what they want, they shouldn't expect it to survive any kind of fancy testing.

Play Minecraft!
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #28 - Posted 2003-08-25 09:59:51 »

Quote

I took offence because you shuddered at my opinion. There's a difference between disagreeing and ridiculing.


I'm not at all surprised that it would cause someone to shudder. The consensus opinion amongst software engineering people (as opposed to people who just code, and don't really think about methodologies, or how to improve their effectiveness etc) is that "not planning == planning to fail" - and the corollary "planning to fail != failing...it just makes it more likely". It's not a unanimous opinion, and there are plenty of fair exceptions that get thrown around, but certainly it's the dominant view at the moment.

rgrzywinski's "I've had to deal with the side-effects of this approach..." is certainly one of the great reasons for not doing it. If I ever find a programmer working for me who does not plan, I fire them. It's simple - they are single-handedly attempting to destroy my project, even though it's probably unintentional (note: if the programmer dies tomorrow, and there are no plans for what they've been doing, then most of the salary and more importantly the time they've spent has just been lost. Project management cannot take place if staff behave in this way. As the PM on the job, *I'm* going to be fired if a programmer ever leaves and I cannot make the team recover in time to meet the deadline [not necessarily by dying, there are lots of reasons people leave mid-project in practice - e.g. IIRC Woz's plane accident that left him effectively devoid of technical ability for quite a while could easily have meant Apple disappeared without a trace had it happened only a short time earlier]).

A quick aside about "probably unintentional" - I have actually worked on a project where 2 or 3 (we were never sure about the third one) extremely knowledgable people deliberately made sure that we could not fire them, because they were the only ones who could decipher their code. Fortunately, they got fired anyway, and the project sufficiently recovered after a six months to successfully ship. I've even seen a case (separate project, and I was an external consultant) where one guy went as far as writing his code in a shorthand of his own - he obfuscated every variable etc as he wrote it. I kid you not.

In practice, if you're a skilled developer, you can get by without planning. And other people can probably read through your code and look at the comments, and fairly quickly work out what you were doing. However, there is a well-documented and considerable loss in efficiency from this. If it takes you 3 days to plan your code before you start, it's going to take someone else about 3 weeks to fully decipher that plan if they've only got your code to go on. Obviously, the ratio varies considerably from project to project and industry to industry (and even from person to person) - but most of the time it's a big ratio.

You also make every bug more expensive, in terms of money and/or time lost. The classic chart of when a bug can be fixed, as used in the software engineering disciplines for several decades, shows the progression of fixing a bug at each stage in the dev process, and goes something like this:

1. Specification
2. Design
3. Prototype
4. Gold
5. Customer (i.e. it's already been deployed, and you have to fix it at someone else's server / PC / home / office)

Experimental data has shown that each stage increases the cost of fixing a bug by a multiple of 1.5 - 5 (IIRC). So, fixing a bug by writing a second prototype typically has cost you about 4 times as much as it would have if you'd fixed it at the Spec stage. And it could be as much as 25 times as much.

Now, that seems a fairly good reason to shudder when someone says they don't usually plan their projects. I'd imagine that if someone really did shudder, it's probably in sympathy or pity for the person who's wasting so much of their time.

Personally, I don't mind what other people do, unless I'm working with them, in which case I exert zero tolerance (I refuse to have my project screwed up by someone else's anti-team behaviour). I try to educate people of the evils of not planning, so they can make an informed decision, and usually save themselves much time and hair-pulling, but I recognise that some people really don't like it, and are more concerned with enjoying spending more time coding, even if it means it takes them longer to complete.

malloc will be first against the wall when the revolution comes...
Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #29 - Posted 2003-08-25 11:19:01 »

Quote
It's not a unanimous opinion, and there are plenty of fair exceptions that get thrown around, but certainly it's the dominant view at the moment.


Exactly, and I'm one of the people who disagree.

And if you fire people who do what I do, remind me to never work for you. Wink It'll save us both a lot of time.

Play Minecraft!
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.

BurntPizza (24 views)
2014-09-19 03:14:18

Dwinin (39 views)
2014-09-12 09:08:26

Norakomi (68 views)
2014-09-10 13:57:51

TehJavaDev (93 views)
2014-09-10 06:39:09

Tekkerue (47 views)
2014-09-09 02:24:56

mitcheeb (68 views)
2014-09-08 06:06:29

BurntPizza (51 views)
2014-09-07 01:13:42

Longarmx (38 views)
2014-09-07 01:12:14

Longarmx (44 views)
2014-09-07 01:11:22

Longarmx (40 views)
2014-09-07 01:10:19
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

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!