Posts Tagged java

Voxel Game : Shader bugs!

An amusing bug occured today when I somehow linked the main shader to the UI system by accident, resulting in this:

In other news, the entire Entity system is now XML driven.  Entities, their behaviors, polymodels, allowed actions, and statistics are now loaded from an XML file when the main game state engages.  It’s made the code a lot cleaner, and will make it very easy to generate new units and scenarios.  The XML currently doesn’t handle the world setup except for determining the size of the terrain, but I plan to add that.  I’ve also added some actual models beyond simple spheres/cylinders, but they’re still pretty simple.

I’ve attempted to introduce Frustrum Culling, but my algebra is still a bit rusty and it usually ends up culling the entire world out, instead of just the things outside the Frustrum.  The game also now has a win condition! If all the non-player Entities are eliminated, then a popup shows up saying you’ve won.

Tags: , , , ,

How not to do collision detection

Among other optimizations that need to be made, collision detection was one of the ones at the top of the list.  Doing it the brute force way is very crude.  The brute force way being take the list of objects on the screen, and compare it to every other object on the screen to see which ones collide.  This creates a rapidly escalating number of comparisons the program has to execute every cycle, which rises by the power of the square (n^2).

Last night I implemented the QuadTree algorithm to sort out objects and reduce the number of objects that have to be compared by determining which objects are close enough that they might intersect.  Things on opposite sides of the screen, for instance, can’t possibly intersect, so we can skip computing their collision.  It reduced the time it took for a cycle of the collision thread to complete from ~20-30ms for 200 creatures, down to an average of 4ms with 300 creatures.

Then I came into work this morning, where I had left a previous version of the program running over night to see how it handled extended running.  This version was using a ExecutorService and thread pool to help compute collisions in a brute force manner.  I’m still not entirely sure what happened, but this was the result when I came in this morning.  Note the execution timers in the top left.  The collision thread is now taking over 1,000,000ms to complete!  (that’s 16 minutes!)

silicon_death

Tags: , , , , ,

Silicon Evolution

Since working at Menlo Innovations, I’ve had the opportunity to greatly increase my programming skills, especially in Java.  As a result, I’ve spent weekends tinkering with new programming projects.  One of the things that has resulted from this is a little program that takes no user interaction, it just simulates a bunch of polygon “creatures” as they live, grow, reproduce, and die in a simulated world.  I was inspired by the classic “Game of Life“, and decided to make a life simulator.  I chose to make mine a little more complex, and it has some very basic natural selection and mutation added.

Here’s a screenshot:

siliconLife
Pretty happy with it so far. There is a separate thread for the FX, creatures, food bits (green), and the collision detection.  Each thread draws screen frames independently, which are then composited together to make the final frame for display.  Future plans are to make a wider variety of behaviors that the creatures can express depending on their individual “genetics”.  I also hope to add some more things to give this simple world of lines seem a little more depth.

Tags: , , ,