…see something on the screen.
I’ve been learning Slick and the editor Tiled along with worrying about if I’m abstracting my classes enough. I worry my code isn’t organized enough. Worried I’m going to have to rewrite too much. I’m worried I’m developing way to slow.
I said f it and just threw up a self made map with original art work. How nicely motivating.
How about u?
Each developer has his own speed, his own rhythm. I prefer taking care of the modeling of the application at the beginning to avoid wasting a lot of time later in rewriting all. Do you know UML?
No, hadn’t heard of it.
I did a quick google and many people feel it is a waste of time for game dev.
http://www.gamedev.net/community/forums/topic.asp?topic_id=192120
Lol I disagree with them. Lots of game programmers want to be “close to the metal”, use assembler/C/C++ only, no UML, no design pattern, … As you use Java, you already disagree with what they say on gamedev.net 
so true. 
What I’ve learned is that you should either create UML diagrams in the design phase and then generate the code from it or generate the UML diagrams from the code after implementation (for maintainability).
I spoke about UML but the most important thing is that we should avoid to directly code, we should think about the modeling of the application before coding whatever the way. If you prefer Merise, it is up to you
I’d much rather spend a week making something than spend a week planning something.
Design isn’t hard. Especially not in java. Refactoring is your friend.
It depends on the size of the project. I agree with you, design is not hard but a refactoring can require a lot of time on a “big” project. I prefer coding too but thinking about the design is not in contradiction with coding, you can (and you should) do the both.
You shouldn’t do that either UML is for expressing concepts that are either hard to explain using human text or to capture and explain them more efficiently - Or to use a cliché: “One picture can say more then a thousand words”. It’s also given this that UML was created in the first place, ppl used graphics to relay information in their documentation. To improve that experience they standardised by merging a couple of more wide spread used styles that predate UML
http://www.smartdraw.com/tutorials/software/oose/tutorial_01.htm
Now sure UML fits with code generation as it’s less verbose then the actual code, but then it’s more so filling it’s actual use then actually having something to do with code generation. As for generating UML from code; I haven’t see any useful examples of that yet. Usually you end up with a picture that contains a shitload of unnecessary details making it really hard to find what your looking for. Which totally defeats using it for documentation or relaying stuff one from person to the other. The same stuff that applies to ‘normal’ documentation applies to UML. So stuff need to be to the point… etc.
@Markus_Persson As nice as that might be when your working alone, also you can’t refactor out architectural flaws. for example distributing load over the graphics card and the cpu, Or your update scheme(network), etc. Now that doesn’t mean you should design everything up front or even start out with designing hell there is always trivial stuff to be done and loose® coupling is great. That and as a game developer you can just dump most stuff on your middleware your building on. That being said we probably don’t really disagree here we just label design activities differently.
Remember boys and girls there’s more to UML then class diagrams and not hey are not the most significant either.
When coding in Java, it is damned nice to know you have an up to date back up of your work to fall back on should you mess things up when trying to improve your software(game).
Or when you decide to install linux as a dual boot then when that goes pear shaped, you remembered to back up the folder on the desktop because the back up on the usb stick was like 4 versions behind.
No matter how many times i get burned by this i dont seem to learn,on the other hand if you have too many versions lying around make sure you know which one you were working on last…hmmm im sure i changed that piece of code…eh how come im getting all these errors, what the hell why doesnt this work anymore.
Ah the joys of programming and not keeping house in order ;D
ah that reminds me update the usb stick … ;D
What about versioning? SVN?
[quote=“Mr_Light,post:10,topic:33580”]
This is very true. =)
I think I was mostly doing a knee-jerk reaction against waterfall projects.
I think it depends on the complexity of what you are about to embark upon. The more complex the more planning. I guess you have to find a balance that will work for the project at hand.
Other than that when coding in Java, it is damned nice to have fun
// Json
A generalization of “seeing something on the screen” is getting feedback of what you have done. The sooner you get feedback, the better. The best method that I know for getting feedback of code, is writing tests using TDD. When you write new test code and production code in cycles of less than one minute, and running all the tests takes a couple of seconds, you get immediate feedback of whether your code works or not, which in turn makes programming more fun.
TDD also gives feedback of how well the code is organized and abstracted. With TDD you are changing the code all the time, and if changing the code or writing tests for some behaviour is hard, the design has a problem and needs to be improved. It helps in writing the “simplest thing that could possibly work” - just enough abstractions to keep the code flexible, but not too much to make it overly complex. Because TDD forces the code to be testable/decoupled, you end up doing more object-oriented design, which is also fun.
And because TDD gives you a regression test suite (TDD is a design technique, but regression tests are a nice side benefit), you can change the code without fear of breaking something. You can improve the design step by step, so if the architecture is not good, you can fearlessly make it better without breaking things - refactor and rewrite some parts until you have a better architecture. When the code is well decoupled, you don’t need to rewrite everything, even when doing big architectural changes.
I use UML very rarely. In the beginning of my programming career it was useful in putting my thoughts together, but nowadays I don’t need it for designing. I might use it for communicating my ideas to others. I can easily keep the design in my head and I know that the simple things will be solved on-the-fly when driving the design with TDD. For complex things, such as message passing in a distributed environment, I may draw some diagrams on paper. The design that I do without writing code (mostly in my head, sometimes on paper) is at the level of subcomponents (each maybe 1-20 classes in size). For class and method level design I don’t use any diagrams - those parts I can design better when writing tests and when refactoring.
One thing that I always design on paper, is user interface design - finding out what are the users’ goals, defining the functional requirements of the system and testing that the users can reach their goals with the system effectively. For a medium-sized project, that will take one or two weeks, as a result of which we have specified and tested, using a paper prototype, that what is the problem that needs to be solved, what kind of system will solve the problem and how exactly the system should work.
I have to agree with Jackal von ÖRF myself. UML is a decent communications tool but it’s pretty lousy for anything else. In particular I wish people would stop trying to use it as a code-generation mechanism - there’s nothing worse than classes upon classes of generated code from a UML diagram that looked pretty on paper but is entirely impractical from an implementation point of view. Keep your UML diagrams on whiteboards when discussing things and ditch them when you’re done.
As soon as you start keeping UML diagrams around long-term you either head towards Big-Design-Up-Front (because the design can’t be changed) or your documentation ends up rapidly out of date (so it becomes useless and no-one bothers to read it). Something like TDD goes a long way to keeping your design robust and fulfilling the requirements but without locking you down to an architecture someone came up with in a meeting room a year ago.
I as of yet haven’t found UML useful for anything. I also worked with one of the engineers from Halo who was also the engineer lead on Stubbs the Zombie and the project lead on Hail to the Chimp (all AAA titles with big teams), and one of the first questions I asked was what he did in terms of initial design. I was surprised to find that he does practically nothing. 
Usually before something is implemented it is discussed how it would best be implemented (on a purely implementation-based level, no discussion of classes, etc.), then as you’re developing that you follow coding standards used in your project so that your new code fits in. It worked fine for us and continues to work. I don’t know if this is an industry-wide style or anything, but this programmer is definitely top-rung in terms of experience and ability, so I imagine he knows what he’s doing.
Even so, I agree that in the end it all depends on the project.
I vote against UML for game, IMO this result in an absolute ineficient code, game are usually not that complexe (even big AAA title are not that complexe if you look close), also several time when you have made your pretty UML modelling without doing any test verifiation in real world you start coding and realized “ouch this will never work”, cause UML is theorie not reality and when you fall to the reallity you realise for exemple that creating a Color classe was not the best idea when dealing with thousands of pixels.
I thought this thread was…When coding in Java, it is damned nice to (fill in the blank)
not that im complaining or anything :
UML??? whatever happend to scribbling ideas for program flow on the back of an envelope or scap paper you have laying around?
feel free to delete this post after youve moved the uml discussion into its own thread
oups sry,
IMHO, when coding in Java, it is damned nice :
When coding in Java, it is damned nice to not use UML