Added GUI and some budget sky background images.

[timatooth]

Not very fancy images made in gimp.

[grimtastic]

So you must have used the code that was there before my big update :( hmm...

[timatooth]

I thought I merged it in on sending a pull request from my own fork to merge GamesRepo into it on github. Never going to do that again. Trying to sort this out from the cmd line. If all else fails ill just add the changes manually in a fresh repo.

Edit. damn I am quite a few back. I was working on code back to https://github.com/OtagoOpenSource/GamesRepo/commit/a6cecd09241c576ca0964f524190c9ac7298457d

[grimtastic]

I've got it working with the current code in the main repo. Want me to push it or leave it up to you?

[grimtastic]

The main problem was that I decided to make a couple new packages to sort things better and better named the PlanetWorker class... Wonder if there's a way to make big changes like this in future without disrupting other people.

[timatooth]

Please do! My git and code is a mess full of <<< HEAD stuff from trying random branching and merging and automatic fixing tools. I should have double checked that I was up to date before working on it.

[grimtastic]

Pushed. You might want to check it out to make sure I didn't miss anything.

[timatooth]

Just tested. All seems to be working the same.

[grimtastic]

The Main Menu is best to have its own AbstractAppState class. It doesn't really matter that much, but as the Gameplay class was registering clicks, i.e. adding planets to the game, while the main menu is open, I decided to move it to fix that at least.

[timatooth]

That's a good idea I was wondering about that wasn't sure whether or not to put it in it's own state or not or how it should be done right.

[grimtastic]

Yeah, generally speaking I think how it's done is you separate each different state you can be in into its own class, e.g. Main Menu, Options Menu (if that isn't part of the Main Menu), Single Player, Multiplayer, Level Editor, etc. Then, when you wish to change to another state, e.g. click the "Play" button from the main menu, you use the state manager to attach the new state that you are after.

But I'm not entirely sure if I have done it correct. When I made a game for the iPad using a game library called Cocos2D, there were 2 methods for changing the state; pushScene and replaceScene. Push simply added the new state to the state manager, but kept the old state in memory. Replace actually got rid of the old state and replaced it with the new state. If I have done it wrong, then it will mean that we aren't freeing the memory from the main menu when we go to the game state, but I guess it won't matter at the moment. We can leave that until beta testing lol

[grimtastic]

I guess we should have set up the basic outline for the classes from the get-go and maybe had a little tutorial about it. But at this point, if it works it works.