Meh ...

Having fun with MCU's

I almost forgot I had a blog :)
Have to get back to writing some code soon, or else I might die of mental degeneration. But I managed to work on something that is completely unrelated to java programming.

I sometimes like to work with the MSP430 Microcontroller by TI. Those are little chips that can be programmed to do certain tasks. Most people have probably heard of the Arduino, which is an open source platform based on an Atmel AVR Microcontroller. I personally prefer using the msp430 because of three reasons.

• its dirt cheap. the launchpad was 4.30$ when it was released featuring 2 included microcontrollers and  a programmer
• its insanely low power. if properly programmed, those things can run off a coin cell for years
• GREAT community over at 43oh, which is helpful when confronted with problems that are beyond your grasp of electronics, which, for a person that writes programs in java, python etc, tends to happen quite often

Anyway,  for anyone who is interested, this is my latest project, meant to drive a good friend of mine slightly mad.

you can see and or hear it in action in this clip

its just a microcontroller with 4 external components, a 4.7k resistor, 1 2N3904 NPN transistor to drive 1 speaker salvaged from an old laptop and a led to tell me that everything is working fine after i started it.

for anyone owning a launchpad, just grab the code, for anyone else, grab a launchpad first, they're fun :)

More progress

Realizing where the Y axis starts mights seriously help debugging. Most of my logic builds on and origin of xy top left while some api's really want xy bottom left. Eitber way, soft scrolling if working now. Even
on android.

Hello from android

Finally came around To write some more code for my roguelike :)
Writing in english on a german phone is quite annoying though.

Dungeons, dungeons everywhere ...

Sometimes it comes to mind if placing every single tile by hand could be more time effective and yield a better dungeon. but it wouldn't be that much fun, would it?

At the moment i am also a little bit fed up with Eclipse Juno. I use Eclipse since i started programming, but it seems to get slower with every release. As well as eating tons of ram. I might downgrade to an older release until this is fixed.

But first i promised to explain how i actually generate those dungeons.

Generating dungeon like struktures, especially 2D is quite simple. the way i do it is by creating a integer matrix and seeding every field either full or empty using a noise function which is basically java.util.Random.

After all fields have been initiallized with what looks pretty much like white noise, i run multiple iterations of a cellular automaton over the matrix.

for every cell of the matrix i count the 8 cells around it as well as the cell itself. if 5 or more cells are solid, the processed cell turns or stays solid. if less then 5 cells are solid the cell itself turns empty.

5 to 8 iterations of this create a smooth dungeon without single pixels in the void or other artifacts.

now i have a beatiful dungeon that is nice to look at but useless in the context of solvability. The naive algorithm used to create the dungeon does not ensure that the dungeon is solvable e.g. you can move from point a to point b. There might be walls that make the dungeon unsolvable so we need an approach to fix this.

My first solution was to place 2 starting points in the dungeon. those starting points are placed at two fixed position depending on dungeon size. The position will then move randomly until the start and goal point fullfil two conditions. the first condition is that the start [ or goal point ] is in free space. The second condition is solid ground right under this point. 

This way the start and goalpoints _wiggle_ themselfes into position until those conditions are met.

Then i need to check wether the dungeon is solvable or not. This is done using a simple Astar implemenation.  My first attempt completly ignored heuristiks because i deemed them unneccessary to determine if the start and goal points are connected. Because of a flaw in my algorithm this didn't work and you can see the results  a few posts below. Luckily i found a few Astar implemenations on the internet and was able to bend it to my will. If the dungeon is not connected i simply generate a new one using the next seed i get from the PRNG.

Now i have a dungeon that looks nice and is connected. I fixed up a small routine to render those. I also added another cellular automaton that fills the dungeon with some vegetation. As of now it just places some entities on the map with a specific ruleset, but in the future i want to place those entities randomly on the map and then let the entities life. Water, for example, could pool up in certain areas, create moist places that lead to _shroomy_ surfaces on the ceiling or to grass growth etc. I have to get a few additional ideas what to add, but once you have an infrastructure to add those entities and then implement a simple ruleset how they behave, its quite simple to add more.

This way an otherwise sterile dungeon will look more organic and thus more believable.

I also have to work on the sprites, the grass texture, for example, is a placeholder i took from minecraft hoping i won't get sued before i replace it with something i can draw. I am also getting better at using Gimp.

In the end it pays off to write a little code rather then doing it all by hand. i can now generate dungeons that are virtually endless in size. the example pics are quite small, mostly because a browser would have problems displaying them otherwise and i have a very slow upload. Since google does not want 8192 x 8192 pictures uploaded to a blog, here are the dropbox links for anyone who wants them [ 0 , 1 , 2 , 3 , 4 ]  

Here are now some screenshots. Its in no way a game, those are just renders to a BufferedImage to test the dungeon creation algorithm. Maybe this turns into a game, we'll see.

If it does i think i found the right library to do the job. 

LibGDX looks awesome. Write code once and deploy it on any Desktop, Android and Browser, maybe even iOS soem time in the future. It also enjoys a very active developement [ making it hard to find an up to date tutorial ] and has great documentation.

Hope you enjoyed this. Good night :)

Finally

Now those are some nice connected dungeons :)

i will tweak the start point generation to be more _random_ but for now i like the results

A*Star fail

Hey,

just wanted to make a quick post, finally found some time for recreational programming again ^^.
Here is an implementation of the A*Star algorith WITHOUT heuristics.

this might still need some work. Its meant to be a cave generator for a plattformer at some point, but as you can see, its still a very early prototype consisting of a prng and a cellular automaton

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.

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

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 :)

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 ^^

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.

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

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.

StateBasedGame rocks :)

After some code mangling and re-factoring i finally managed to get it working the way it was BEFORE i started updating it.
Using states to program a game works great. you put every possible view into an own class and eventually create a very simplistic state machine for your game.
this way adding a menu screen, credits, options, main game view, research view and any other view is no problem and it probably saves on performance because you can control exactly what calculations you want in your update method and which not.
i started implementing the planet view, which will be the actual game view when you are managing your solar systems. I've added a screenshot that just shows a proof of concept. now i just have to figure out this.

More coding

So, finally a few things are working now.
We have a fully procedural generated galaxies with randonly generated solarsystems that contain randomly generated planets. This is nice, especially because its quite scalable, i could just stack galaxies or make them bigger and it just works.

Grafix are working ok too, still looks very rudementary, but i could never finish anything if i would to the gfx myself, so randomly generated is good enough, maybe needs some tweaking.

The Screenshots i currently provide are actually only for debugging. Now i have to start writing more code to turn this debugging view into a State based game. Slick2D works great this way, at least as far as the examples and tutorials suggest.

What i need now is a sepereate view for research, solarsystems and planets which might take a few hours to complete :)

This looks much better :-D

this looks much better, but there might be some scaling factors that need some fixing, the big "planet" in the middle is supposed to be the sun. so some adjustment might be justified

Making progress

which is hard to visualize

now we generate solarsystems instead of planets, and while the generation of planets works fine, the sunsystems might need some tuning. The code for the planet generation was from Bonbon-Chan @ java-gaming.org, a forum that is a great help.

On another note, all the sunsystems are actual sunsystems with a randomly generated number of planets and different types of planets. i use a gaussian random from 0 to 1 and then multiply it with a maximum number of planets we want in a solarsystem.

on a technical note, smooth scrolling and zooming now works

so where am i

scrolling, zooming (barely) and the minimap works :) and seems to run quite snappy as well :D

i still have to figure out how to associate every mouseclick with the right planet to finally give this some meaning and the ability to start experimenting with buildings, ships and so on

Some progress...

Generation works good, Galaxy looks a bit blocky because it's currently rendered depending on its position in an array. Planets should have other options for placement then to check in an array, maybe something depending on the distance between planets.

The Planets should also replaced by Sunsystems that will render if zoomlevel is too high to show all planets. On high enough zoomlevel sunsystems are rendered as individual planets.

also resolution of the planets should be reduced.

funny enought, planets have different sizes, which is currently almost invisible.

the size of the planets is between 40 - 310, i calculate a scaling factor with  1 - 1 / sqrt(size) which should be improved