Getting off the ground

[theraje]

It seems that the main thing that's keeping me down in Java is a lack of organization and planning. When I was coding VB, I could just get an idea and run straight to the code window with it. Doesn't seem to work that way anymore since I switched to Java.

So, what kind of planning or documenting do you do before you go on to code your project? An example design doc (abridged, of course) would be great. An article on writing a design doc with Java in mind would be nice, too.

Thanks!

[Jackal von ÖRF]

I usually make just a UML class diagram. If the program is too large to fit in my head or there are also other people working on the same project, then it is better to write more documentation. Search for some books about software engineering to get more information.

Here is a UML class diagram that I made for a recent school project (University of Helsinki). The program was a simulator for comparing network routing algorithms, made in Java, some 3000 lines of code. I left some of the less important classes out of the diagram.
http://www.orfjackal.net/temp/uml-example.pdf

[digitprop]

I don't know - too much design before coding is usually a waste of time, as it is nearly impossible to anticipate all problems in the very beginning.

If you do it right, it's probably at least as much effort as designing by coding. I like the extreme programming paradigm of refactoring early and often - I usually make UML diagrams on the fly, on paper, when I need to get a good understanding of the structure I am working on currently.

I haven't experienced Java projects to be especially difficult to start. Having a powerful IDE is crucial for larger projects, though, for quick navigation between classes.

Games published by our own members! Check 'em out!

[blahblahblahh]

I don't know - too much design before coding is usually a waste of time, as it is nearly impossible to anticipate all problems in the very beginning.

Not to get personal about this, but ... that's the opposite of what most of the rest of the world believes and has experienced.

Design before coding is never a waste of time, and if done competently should always save considerable time in the long run. If your experience is different, that suggests that there are major tricks and methods for design that you've not yet discovered. YMMV, but I would strongly advise everyone in this position to keep at the design-first until it clicks...

[princec]

IMHO he's right. Design in code. Much easier, and you get to use it directly when you're done. It's a kind of mixture of RAD and XP.

Another reason for Java being such a pain in the arse to get anything done quick is that the APIs are royally hard to use for games (AWT and Java2D, stand up and be counted). You might want to try LWJGL if you're really interested in games programming.

And the final reason is that people keep on confusing object oriented programming for a cure-all design solution. Half the time it actually gets in the way of getting anything done at all. I call this phenomenon object orientated wank. It afflicts us all from time to time. Get over it and learn to love static methods! They exist for a reason.

Cas

[cyberyoyo]

I have some experience with a few completed game projects and I am personally alergic to too much pre-code design, and I am repulsed by things like UML. If I were to make a UML diagram I would probably spend all my time admiring and optimizing the diagram and I wouldn't start coding at all.
I think the best option is to have a good and clear view of what your project should be, in your head.You must also have enough experience to know what you can do and what you can't and restrict yourself to the former.
Before starting, divide your project in intermediate steps corresponding to what you can identify as the difficult parts.and write down this roadmap somewhere (I use notepad). Try to think modular and if possible make little "bricks" of program that you can use elsewhere and to help you build the whole.
While coding you'll probably think of things to add and you'll notice bugs to resolve.As soon as you think of it you should write it down (for future processing) and come back to the task you are dealing with.
You must make a hierarchy for the importance of the different  tasks, solve the urgent problems and code structural backbone in first , at the end you'll take care of bell and whistles.
Anyway I am working alone and if I was part of a team things would be different and I'd probably need diagrams to explaion things to people.

Now to come back to your particular case, I think your problem is a lack of experience with java because there isn't so much difference between java and VB , if you could do it in VB there's no reason for not being able to do it in java.
you are probably confused by the  different structure of the Java code,you should take a look at some simple algorythms and examples because Java is generally a good language to let your ideas flowing.

[KONI]

At university, we have a special course on how to organise yourself BEFORE coding. We get a quick overview on UML, OCL but also on class diagrams, protocol diagrams, time diagrams, Use Cases etc.

It is never a waste of time to THINK and to STRUCTURE before starting the real developpment.