Cant you just post the user credentials to the login form and check the http response code to not be 403?

A good practice is to use the scheme

<major>.<minor>.<bugfix>

where major versions only change, when you have incompatible changes (like changes of the save-game format), minor versions change with feature-additions and bugfix versions change on - well - bugfixes

Nope. As nexsoftware pointed out, doing a desktop only project is just a normal java project with the gdx jars in the classpath. The ui and separated game project stuff is just if you target multiple platforms...

@HeroesGrave
Actually its not about stopping people from using LWJGL once they decided, that they want to use it. its about giving the hint, that if they learn something new to make games, they might be better off jumping to libGDX directly, because it gives them better options to make an advanced game once they overcome the getting started block. there are just more features and integrated tools in libGDX. also there are a lot more people making actual games. getting android support is the next plus if you intend to earn some money.

sure you can do games with LWJGL, but its way more work to get a polished non-trivial game done. There is just too much temptation to burry yourself in fiddling or ending up doing an "engine", eating up all your time. I've been there, burned my spare money, and am back to J2EE now, so might be "biased" - decide for yourself...

But maybe I am wrong. Maybe its better to start with pure LWJGL. youll need to do a bunch of simple (pre-)games to learn anyway, so why not do this in LWJGL, just to get in touch with native libs, low-level data structures and math and do a more educated decision if you are on the verge of creating your own engine or library...

There is an "appreciate" button on every post - just press it for posts you - well - appreciate


This is exactly what you should try to avoid: making your mind about stuff thats not related to the core gameplay/design.

There was a lot of discussion about how to secure a games content, it's networking, the highscore-table etc. Common wisdom is: just dont!

If your game is so successful, that people want to pirate or rip stuff out of it, you are a winner! Chances are, that nobody is interested in doing so - at least for your first game. And even if - what should they do with the art? If they do a fan game inside of the same universe - you should encourage and support them! If they use it as "placeholders" in their own hobby-game, you should feel honored.

Just provide some copyright and licensing readme along with your game and inside your games jars, so you can legally claim ownership of the content.

You are new here and Riven runs this place. He probably knows, what you wants to know, but he surely is more experienced than you - so maybe you should be listening and thinking about what he says.

But maybe you are not interested in finishing a game and more into "technology-wanking" - that's OK, but you should be aware of that...

just use your name or nickname as toplevel package. then use subpackages to group things you want to group like you are usually using folders. you may also put the projects (code-)name in the middle,if you want... as long as you don't want to release your code as library, dont bother too much about packages. just dont put any classes or stuff in the default package (toplevel without folders), and you'll be fine. even this advice is actually just common convention and might only be relevant if you use classpath scanners or get deployed in a shared environment with classloader hierarchies...

common starting points are arcade classics like space invaders, pac man or breakout, but you are not limited to them. the important bit is too choose something you can turn into a finished - and hopefully fun - game without learning too much new stuff.

so ideally only once you created a finished (mini-)game for every feature or aspect of your planned game, you should start working on it seriously.

if you want to create games for living and have a low budget and finite time/resources, then avoiding existing engines wil make sure you'll fail!!!

my advice would be to jump into libGDX instead. it will give you neccessary boilerplate code, good performance using opengl and android support out of the box. and if you really want or need to, you can still drll down to the low level by doing opengl and gpu shaders yourself.

but dont be fouled, if you want to do games for a living, you'll need every help you can get as well as spending HUGE amount of time to polish and balance your game. AND THEN you'll also need a truckload of art etc.

so save your time at coding and concentrate on gameplay/design and art/style. maybe leveraging prior expertise by creating a sound related casual game...

They just mean, you need to finish a game or something similar on each level of your abilities on your learning curve.

The biggest problem for people creating games here is that they either think too big (ala "My first project will be a MMORPG with Crysis like graphics") or they get lost in details (ala "I want to do a top-down scroller... but with 3D background... so need procedual generated terrain... but with dynamic lighting ...so need Shaders... but want Caves... so need Voxels... etc.)

So it is most important, that you finish something with your current abilities before you go on.

Otherwise you either spend all your time on some highly complicated and sophisticated part of your (never-existing) game or you loose interest alltogether, because you never reach your goals.


Yeah, experts would plan ahead based on their expertise, but if you are just in the beginning of building it up, you can only plan ahead to your horizon - you can't see any further. But the nice thing is, once you reach your that limit, it will have moved (by approx. 4.8km ) revealing a completely new world to explore...

So leave a mark (finish something), and move on! 

Oh people stop that system.out nonsense - learn to use a debugger. You'l solve stuff like this in minutes using one...

Pay attention that
is mandatory for the sketched algorithm to work. If you use entity coordinates that are centered to the entity, you will miss collisions with big entities!

In most cases you wouldn't as long as the entities are small enough. You would rather widen the maxRange in

to search enough cells, so that the biggest entity you would expect is also covered.


If you really have huge entities, you could just attach an array of offsets to the entity coordinates that would form a coverage grid with the same cell size as the playfields grid:

This way, you would add the entity to as many grid cells as you have covered.

Unfortunately that is the key-repeat from the OS, so nothing java can do about :/ Afaik, the only way to overcome this issue is to use a lib with native bindings like JInput.

Because of the way people tend to manually align stuff with spaces. The whole formatting falls apart when opening such a file with different tab settings.

Actually in Idea it is not much of a difference - but I also prefer tabs.

Take a look at the Code Style options and check "Use tab character"

You mean standard in ECLIPSE - ever thought about other people having different preferences? I know enough people that want spaces for indentation. Especially larger teams tend to use spaces instead of tabs to overcome indentation-mess when not using code-formatting on commit...

If it is too much effort to look beyond your nose - just let it be

I am afraid, you have to move the cursor one character to the left before hitting Alt+Enter...

Ah, ok - I occasionally "attach" the missed grid cells at the wrong side of the found one. I probably won't put any effort into fixing this, since I doubt it will beat your implementation.

especially logging! log to slf4j, which binds to commons logging, which appends to jul and ends as a S.o.println anyway :/

well its a shell to script beans - hence java classes. you can run it interactively from the commandline, so youmight get a better environment for interacting with your classes. there is also groovyshell http://groovy.codehaus.org/Groovy+Shell#GroovyShell-Features which might offer more features.

OT: man - I hate posting here from my 2.3 android phone. does it work better with 4.1?

Take a look at beanshell: http://www.beanshell.org/home.html

But java is not the best shell language, so learning bash might turn out the better decision...

The it's Eclipse - I hate it anyway - use a better IDE *runsForCover*

Actually most game apis for java use OpenGL and bypass Java2D completely. I would go for libgdx directly - learning Java2D will leave you with unused knowledge in the end - at least api wise...

You don't happen to have special characters in your turkish abc that look like c or 2? Or have some extra space in the filenames?

What about the security settings of that file?

Did you copy the files when it worked on D: or did you recreate them there?

Dunno, but don't use filenames anyway, use URLs you get from getResource(), so it will work as long as your images are in the classpath - even if they are in a jar...

See http://www.java-gaming.org/topics/jgo-frequently-asked-questions/26316/msg/230171/view.html#post_how_do_i_load_resources. The principle is the same, just omit AsStream if you only want to get the url for apis that don't take inputstreams.

- (Vector-)Math... yes even for 2D!
- Art
- Someone who is good at art

I use it at work with project consisting of 50 maven-modules. It's still useable (and maybe better than eclipse), but it is definately not MUCH faster and it does not use less ram either...

Just a reality check, no bashing...

well, you hide, you shoot, you hide, wait for regeneration, then you shoot, you hide, wait for regeneration... doesn't that ring a bell???

As much as I like Idea, this is highly dependent on the type and size of projects you are working with.

Did you play it? Its really the prototype of a modern FPS