- This is for 2D games with a moving view (like a side-scoller or an RPG) that have a background painted using images and java2D primitives like lines & java.awt.Shapes. When an AffineTransform is used to move the view, you may notice ‘jiggle’, where the images and shapes move relative to each other even though they’re meant to be a static background. The reason is that the images are painted on the nearest pixel, but the shapes can be painted across pixels. To fix it, just set the AffineTransform’s translate operation to an integer, not a decimal and then there shouldn’t be any jiggle since both shapes and images will be painted to the nearest pixel.
- Think in detail what you are going to build and make as much of a plan as possible before you start. Then look at all the available libraries and other resources that can give you a head start. Writing a game is such an epic task in itself that you’re going to need all the help you can get if you’re ever going to get it finished.
- avoid combinations of parentheses and numbers that result in smileys instead of other things.
EDIT: Also, always read the thread properly
Sorry, what do YOU do in the Games Industry? Are you a full-time Lead? If not … what are you talking about? I’m talking from the position of a professional who’s been working in the games industry for almost a decade.
Of course, maybe I have no idea what I’m talking about. Unlikely, but I’m willing to entertain the idea…
- Make sure you have a basic understanding of what the java memory model guarantees you before trying to reason about how threads interact.
- Try to use high level concurrency primitives where possible. Sprinkling ‘synchronized’ around your code is deadlock prone.
I write every line of code with the thought that I’ll have to refactor it later (so I try to only write code that’s easily refactorable).
My reasoning is that I don’t have a complete plan of the game that I’ll end up creating as I tend to get inspired with features when things start to get playable and fun. Which is the point where I want to get asap, so I know if it’ll be worth it at an early stage.
Dunno if this is worth being number 26, but there you go 
Hey, come off it, he’s definitely right - disagreeing violently can be bad for your health (see blood pressure). Are you allowed to tell us what you do for a living now? I’m sure quite a lot of folks would be interested and excited.
I came up with a new one:
- Always change the diaper first, then the outfit - or run the risk of pee all over it. I know, I know, but I’m learning
Most everything thats been mentioned here is good software practice generally. Good stuff.
Kev
Sorry if I misunderstood g666’s intention, but I took it to be that disagreeing violently was generally a sign of being wrong
I have seen people lose their jobs over doing stuff as stupid as the points I disagreed with. I consider it extremely poor to advise people to do that. Several people I know were actually taught to do it, and that’s grossly unfair - I’d go to a lot of effort to try and prevent anyone else from being screwed that badly.
Haha… making a perfect plan… yea right ;D
28) Prototype.
If you’re doing something different, prototype it. Many things which sound fun in theory dont work in reality at all. Or they require lots of drastic changes and experimentation.
Fuzetsu for example wasnt planned at all. It “grew” into that direction and after dozens of iterations (yay for scripting) I had something which was fun.
I’m currently trying to prototype my turn-based combat mechanic in Flash. That way I will know what I want to build in Java before I start and hopefully have ironed out most of the “not fun” variants on it.
It’s reminding me why I hate ActionScript so much…
Re: “Perfect plan”
If you are working in a professional team with ppl making art, music, 3D models, menu systems, game editors and so on, then it is naturally important to have a quite detailed plan so that everyone is working towards the same goal. For a hobby project with a single developer, then it doesn’t seem like a good idea to create a complete (definitely not perfect) plan. I normally think about an idea for quite some time before I start coding. The real fun stuff about developing games as a hobby is that you can change things around quite a lot as you code, to give the game that right touch that many of the big games lack (quite possibly because of a strict plan).
Look at puppygames. I’d be willing to bet that most of the “plan” was just to create a game with that right touch.
My approach is to always make the best plan that I can, but design in the expectation that the plan will need to change and be ready for that…
29 print more pearls of wisdom
30 goto 29
- Always finish and release game before offering pearls of wisdom about finishing and releasing games.
Cas
btw, we never had a plan, all our ideas just sort of evolve out of nowhere. The code is hacked and buggered about until it behaves.
Cas
-
Do backups. Every hdd will fail at some point. Some will last 6 years or longer and others start to b0rk out after a few months.
-
Get an Nvidia card.
- Emphasis on 33.
that was not my intention. i was just trying to say that when people get emotional about arguments they sometimes stop thinking rationally. Also i didnt intend to involve game industry-ness, it was just what i thought after reading your post.
peace 
+1 for #33 here too And #32 come to think of it.
Cas
+1 to #32 with a side order of “life is easier with version control.”
And if we paid attention to #31 this thread would only have three useful posts on it, and none of them mine. Ooh, actually, that’s not right! I do belong to that hallowed company! Never mind, as you were ;D