Well… Let me say this:
- Unity3D
- Android
- Windows Phone 7
- Probably iPhone & iPad
- Windows Azure
… and a bit of strategy for those of you who think Chess is too easy.
So what are we doing?
Steaming ahead down the path of Unity
Yup, that’s what I’m still doing!
A lot of time has been put into exploring the options that Unity3D offers. I’m still not very happy with the very real problems of attempting to effectively use Unity with any source control solution, but apart from that it’s a pretty powerful tool.
Today, I’ve managed to incorporate Facebook integration, WCF web service consumption and communication between the Unity Android build and a regular Android library.
Pretty soon, I’ll be able to reveal what’s going on!
Then what?
So what happens now Musickness has been released?
I’ll tell you what: I’m looking into Unity 3D. Since right about now, version 3.5 Developer Preview Beta, they’ve finally started offering support for third party revision control.
It has a ways to go still, but it’s getting there. Right now, what’s missing is text based project files (coming in the final release, or so I’ve read) and project settings. Apart from that, it looks to be usable in its free version as well, even when there’s more than one person working on a project.
More to come, I hope.
Musickness released!
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.