Finally, Musickness, including the updated color scheme, is through peer review!
Check out the official Xbox Live product page for more information.
Also, here’s a video with the final blue/purple color scheme:
Musickness into peer review
You know, sometimes I didn’t think the day would come. But here it is, my first game that’s actually ready to be released into the wild! Simple, but fun!
This is my first peer review submission to XBox Live Indie Games!
Once again, I have strayed from the path.
This time I and a friend had a weekend of “let’s just code something from the ground up and see how far we get”. Turns out we got quite far. Apart from making an the actual game level, some color tweaking and so on, this is basically a game ready to play.
A bit of wallpaper, some paint here and there, a full game level, a new points system display and it’s ready to rock!
More randomness: Treemap Drilldown
Ok, so I’m still having problems with motivating myself. For that reason, I continue to play with new, random things.
This is a GUI I made this weekend, made to visualize a treemap representation of a game AI decision tree.
Still needs a lot of polishing of course, but it works pretty well for a first version.
Sometimes, you need to do something different
So this weekend I got it in my head that I should render cubes. Lots of them. Since I usually rather make things up as I go and get something working before reading up on a technique, I tried about 10 approaches before ending up with this:
Basically, the algorithm is buffered and overshoots the camera frustum slightly to all sides, making sure that it has time to fill in the blanks before the camera moves too much. There’s still a lot of room to crank up the update frequency before frame rates start dropping, but this is really good enough.
The reason you see blocks remaining after the frustum moves past is that there is an equally lazy cleanup algorithm being run every now and again (about 500ms at this point), and it too is conservative in what it chooses to clean up, just in case the camera would suddenly turn the other way.
Physics once again in place
Ok, so I got a new, custom physics engine in place. It’s a lot simpler than JigLibX of course, but also tailored to the current needs. It uses between 2-10% the computing time of JigLibX, pretty good I’d say.
I ran into another problem with the GC. On the XBOX, it triggers almost exactly every 412:th frame and kicks the running frame time from ~6ms to ~140ms. Thanks for that periodic lag. I profiled the memory usage and found a couple of hotspots where the engine was allocating large amounts of memory and throwing it away each frame. After having that fixed, lags went down, but still occur at irregular intervals. I made a bit of memory monitoring code which triggers the GC more often and voila, problem gone. As far as I’ve seen.
To finish off, here’s a screenshot of the dragon again. This time in black and white. I think it looks pretty good!
Black and White scene
JigLibX just doesn’t cut it
Some bad news I’m afraid. I’ve been making a lot of progress recently and I’ve started to do some testing on the XBOX 360 again.
To my dismay, it turns out that I’m experiencing a lot of lag after just a minute or so of gameplay. I was afraid that I would have to work through my graphics pipeline again, but that shouldn’t degrade over time.
I started profiling my code and after some work I realized that the graphics pipeline was working well within its limits but I found another spike that I hadn’t seen before. The physics engine was performing extremely badly once the number of enemies (and thus collision volumes) went somewhere above 2-5. I attempted to do some threading of selected parts of the code to alleviate the burden, but in the end it just made JigLibX shake like a Chihuahua in the arctic. It simply got terribly unstable, so I decided what I should have decided long ago: I’m scrapping JigLibX.
It took about half an hour to rip everything out and get the engine going again. Now all I have to do it replace everything that JigLibX did with my own implementation. I was hoping it would have to come to this.
Sorry JigLibX. We must part ways.
Video #2
It’s not quite good yet. It needs some animation transitioning and a bit of tuning here and there (left leg, anyone?) but it’s alright for a first try I’d say.
Screenshot #6
Red Dragon
Meet our next contestant: The red dragon!
…oops, I believe the “beard” and “mustache”, horns and teeth have their normals inverted :/
Screenshot #5
New main character in the making