Thursday, December 8, 2011

Cleaning up!

The codebase grows and grows, and something that was once a test how i could render sprites in Slick2D has outgrown the "proof of concept" state, and is on its best way to turn into something more gamelike
So instead of introducing new features it was time for a refactor.
Package names now have a naming convention, so do classes. A logger has been introduces instead of all those System.out.println() as well as a config file that handles settings without the need to recompile the code. A friend was a great help, mostly because he works in a more professional enviroment then me, as well as more experience.

Another think i found was a true "first" in the java programming language.
Destroying an object explizitly in Java.
Apparently when using the Image Object from the Slick2D api, when you create an Image with a content, and then overwrite then content, the old content aparently still takes up memory, so if you rerender an image multiple times, you have a memory leak.
I use quite a nasty method to create the red [ now white, at a later point in color of owner ] overview in the right  upper corner.

Code

I am aware that this code is very bad code, in the beginning this was meant to test the galaxy generation algorithm, so it just created a image of the galaxy. But using it as a real time overview is very unressourceful, so this will change :)

I hope i find a way to render this in a better way, probably rerendering the image every time a star is changed ( owner or existence ), would be quite ok, because this happens rarely. the border and the view finder [ see other images ] will be rendered in the renderer thread with Shapes.

I will also try to get the Imagebuffer local, put everything in one method.

Till then have fun, and please, if you want, leave questions, opinions, suggestions etc.

Wednesday, November 30, 2011

has anyone ever heard of delaunay triangulation ?

if not, neither did i.
i friend who is working on a similar game pointed me in the right direction, so now i can finally generate vias, or starlanes without so much randomness. The algorithm allows me to have a guaranteed connection between all planets without to many and overlapping lanes. it works like a charm, but has pointed out another error i made when i first designed the game. I use an 2 dimensional array for all solarsystems. then i add a random displacement so my galaxy doesn't look like a huge 2 dimensional array. this means i still have overlapping vias, but the situation greatly improved.
The downside is that using this algorithm on 4000 points on a 512 x 512 matrix takes quite a while. I optimised the Galaxy creation quite a bit. so generating 4k solarsystems with ~ 9 planets each and vias takes 21125ms.
If i check how long the vias take, i get an impressive 20478ms. This means everything but the vias take 650ms to generate, then the algorithm eats solid 20 seconds.

I will post additional information later, i have to go now :)

-sascha

Sunday, November 27, 2011

Now with more stars

As I had no motivation lately to improve the underlying game part of the game, i tried to make it more visually appealing. I started creating a background layer with stars. At first i used a simple sprite of a 3 x 3 cross as a star, but since i want most of the visuals to be generated and not saved, i decided to code them as well. I should add some gfx to the background as well, like fractal nebulas etc. but this has to wait. I also increased the resolution, fixed a bug i ha with opengl on my thinkpad t60 that caused the new vias [ the white lines ] and the orbs around the solarsystems to sometimes turn into large polygones rendered onto the screen completly messing everything up.

i like the look the game has now, but i am still missing a usable user input system and most of the game part as in buildings, research and spacecrafts, but this will hopefully be added at some point. i am currently thinking about switching from slick2d to using only lwjgl, mostly because 3d would look better and it would enable nice realtime lighting effects. but i am still not sure about this.

now some more pictures :)




Tuesday, November 8, 2011

Congratulations, its a game

As promised, some pictures. Finally something that looks like a game is emerging.
Building something finally works, although it completely ignores levels :D

The ugly lines  in the second picture are the vias that will at some point enhance transportation between solarsystems.

I am off for now, updates will follow ^^



Saturday, November 5, 2011

Still not dead ...

So i finally managed to care for my pet project again.
I first had to take a good look at the data structure and decided that it needed some modifications.
Currently the data structure consists of a single galaxy that contains a hashmap with solarsystems and its identifiers(keys). Every solarsystem consists of Astronomical Objects with completely incorrect distances to each other. After a post from "philfrei" who pointed me at "Bode's Law" i will probably do some research on this but for kow i want to extend the data structure.
What I did first was to instroduce the Universe, a data structure that contains galaxies. For this i had to rewrite the cascading data structure and i found that i could manage the data much better if i would have every planet, solarsystem and so on in the universe and just use the identifiers(keys) for reference in solarsystems and galaxies.


After this, i will start introducing some actual gameplay, currently placing structures on planets.


Will further update, but no nice screenshots for now.





Wednesday, September 28, 2011

some updating

This game should get some game mechanics. But in order to test these i need a view to support the functionality i want to implement.
What i want first is the ability to build structures on planets and in space. I am currently trying to figure out the most efficient and maintainable way to do this, have to read up on my OOD which is a little rusty ^^.
I also was not completly happy with the procedural textures i provided for plantes and solarsystems, while i still have to figure out a way to render the solarsystems, i was able to improve the way planets are rendered.
I found a pretty nice note on this at http://angryoctopus.co.nz/, i especially liked that he takes the gradients from a file rather then defining them in code. this makes it easier and more visually comprehensive to create and read new planettypes, as i needed lots of them.

i still haven't figured out what the memory leak is all about. It appears as if the programm saves every rendered frame, the memory leakage greatly depends on the resolution my program has and increases whenever i alter the part of the galaxy i view, even when no planets are present which means no textures are even generated.

but now some nice screens :)




when a solarsystem is selected we switch so a solarsystem view, when a planet is selected, we go into planet view.
i want to implement a menu in planetview that allows the user to manage the planet, build stuff etc.
in the solarsystemview the ressources should be shown.
i want the user to be able to manage single planets from start, and as the game gets more complex, he can do 80% of the managing in solarsystemview.

regarding ressources i am not quite sure how i want to handle these. ressources in most games are units of something you can accumulate, like metal and crystal until you need them. i also want to add streaming ressources, like sciencepoints and energy. those ressources will be able to steam in solarsystems, so if you have energy + 10 on planet 1, you can share it with planet 2. there will also be research options to increase the usage of this network, making it possible to stream ressources to neighboring system.

this is it for ideas right now.

have fun

Sunday, September 25, 2011

I don't think this is normal ...

Ok, programm works great, solarsystems look much better now, but only in a wip sense, have to work on that.
But when i checked how much ram my program ate i was confused



i then checked for memory leaks but found nothing when i anaylzed the heap [ except that storing 4k solarsystems with ~9 stars inside of each with corresponding images eats quite a lot of ram ]

i went into an irc channel and checked it out further just to be relieved.
a user called djdduty [ thanks to you! ] tested my programm to reveal  it uses ~ 100 - 150MB of ram on his machine.


aparently i have a 32bit jre and jdk installed on my 64bit machine as well as the 64bit counterpart.
i have to use 64bit native interface for lwjgl because i have a 64bit machine and this appears to be the point where the magic happends that extends my ram usage by 13x times.

i might uninstall the 32bit jre&jdk to fix that, but as of now i can continue programm without worrying about the memory usage because 100+ mb seems totally ok for me. when i checked the heap i found out that all those little images eat not as much space as i thought, so i am on the safe site here as well.