1) aiming for 1280x1024 resolution ? (setSize(1280,1024) in jeu class; right off the bat sounds risky, lots of users will not have monitor supporting that resolution ( e.g. laptops etc. ) If you are making applet, i suggest looking at gamesites to see suggested sizes, e.g. Kongregate has 700×500 limit fro flash games. Now this is not important if you are aiming for downloadable, but in any case you want the user to be able to play on any monitor. A lot of applets break this rule, and lose a lot of players that way.It's good to think about this from the start, and though it may be some work i recommend either setting a smaller size that everybody will be able to play or making it resizable to fit different monitors. For our game we are now pushing it with 1000x600 startup size... this is particularly to fit laptops and netbooks.

3) Indenting code, if you are using Eclipse : Select All, CTRL+I does an automatic cleanup, makes everything nice and readable.

4) As you make more actual game code, you will want to put pieces into other classes, and try to keep the Game class just as the controller of the engine state, with Players, Logic, Map or whatever separated.

Second one: How to do if I want that every time I change number of doode colors, my JPanel changes too.

Because, when I change my variables in the code, or add "nombreDeDoodeRouge++;" when I click on panel, it dont change my jpanel, It's bad for a game if we have to have exactly the same numbers of guys everytime

hmm.. I'm really not very good with Swing. somebody else will have to help out on that.I've mostly just rolled my own games, not really used any engines like JGame, but they could be useful...Also I haven't made any games which just sit still waiting for input,always having a Runnable, which continuously paints everything I want on the screen...

One more thing, you may want to make a Doode class, which has nombreDoodes vaariable inside it...

A few advices : 1. You are targeting to a RTS (is that real time shooter ?), Swing is rather passive (indirect) rendering wised, so it be more understandable to use an accelerated rendering strategy like opengl. 2. A game should be as compact as possible in terms of objects concurrently loaded, as you said a game needs to react pretty fast. Then I'd use one JFrame and several JPanel's for menu, options and maybe a canvas to make real-time rendering. 3. following those advices makes you plently open to further implementations of third party libraries like LWJGL, JOGL, etc. As of 2. you will have your object amount increased by 10 in a later time and your code will stay "open" to high-end API's.

Game design is not a fair work, you may spend more time on coding basic rendering aspects, where you may not have enough time to define a robust Threading concept, multi-player interface or AI simulation...Last but not least, books are not the best tutorials, but school curses (yes, school is teaching game design) or using a library designed for games (google it, but I know about Slick, JME, or even mine JIGAXtended API) make the approach easier to begginners.

I made it with Netbeans, look at the map.Main source code it works for a map5.jpg located in the current working folder (see properties of project in NB).You can run the code with the provided executables.

most mistakes in your samples are layout settings. 1. Adding a component when using other layouts than FlowLayout is done with a constraint : BorderLayout -> South, north... ; GridBagLayout * -> gridbagconstraints instance; etc. 2. And at least one of the component must set a preferredSize if no "fixed" component like JLabel or JprogressBar are present.3. each modification sequence after setVisible(true) must be explicitely validated4. when handling multiple threads, ensure you're in the EventDispatcherThread to make such layout modifications : SwingUtilities are therefore recommended tools.

* : GridBagLayout may generally render a better look and feel, but is tricky.

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