Just wanted to report this: Annemari and myself finally got married a couple of days back, 7th of August to be exact. Phew, lot's of preparation for a single day, but it was all worth it. Everything went well and I'm happy. Seemed like our guests enjoyed as well. ^^
I haven't progressed on the game project, but I have played games. I finished Saints Row 2, it was a blast. Currently I'm playing InFAMOUS, which I bought recently. Great game! Thinking of buying Red Faction: Guerrilla next. So many great games, so little time..
See anything different?
Ok, so I finally got around getting a proper hosting and a domain for my MHGames site, and here we are, at the sparkling new http://www.mhgames.org! Yay! I actually wanted .net-domain, but alas it was already taken (like was .com, .org was my third choice).. Oh well.
So what's new? Here is a list of things I've been doing the past 1,5 weeks:
Now that this site contains both my development blog and my games, direct all your gaming needs to this address, so to speak. I will eventually get rid of the old site, so remember to update your bookmarks, if any!
That is all this time, enjoy the new site and do drop a comment on what you like or don't like. I hope to resume developing my game project now that this site is alive, stay tuned.
Time for an update, I reckon.
Although PolyAnim is generally on hold due to the game project, I made a few optimizations (reducing garbage generation mostly, still quite high though) to it. As for the game, I'm still working on the engine side — BUT — I've written down some things on the game plot and other design! I have a vision of the game beginning, but the actual plot still needs to be thought up. Sooo yes, I don't have much at all, but it's a start. Luckily I don't have too much pressures on the story side, as even if it ends up sucking donkey balls (excuse my language), it's still infinitely better than the "stories" of my previous games combined!
It's been so long since my last update, I've worked on so many things I don't even remember them all. Instead of trying to remember the details, I'll just list the things I do remember:
I have noticed a problem during the development of this game, which was not apparent on my previous game projects (since they were much shorter): I have this annoying tendency to start working on different (sub)projects even when the previous stuff is still not finished. That means I have heaps of unfinished subsystems in this engine, like the particles, scripting, triggers, etc. And I'm already thinking of doing the sprite system and other things as well! I mean, what the hell, it should be bloody obvious I should concentrate on the unfinished things and finish them.. Argh, hopefully I can sort this mess out. Speaking of which, I guess I should start coding the particle system to an usable state.
And of course, to all aspiring game developers: design the game first, damnit! Figure out the plot, setting, characters and whatnot BEFORE getting sucked in the bottomless fathoms of Teh Engine(tm)! Yes, I really should take my own advice some day!
Today's subject: quad trees. Here is a nice little tutorial on the subject.
Until now I was using a naive method of rendering the level shapes (polygons and circles): I looped through them all, did a bounding box check* to see if they're visible in camera, and rendered if they were. This works fine for small levels (and indeed for the current test level, although I keep adding more and more stuff to it — nevertheless it's still quite modest in size), but for larger levels it can become a problem, especially on slower machines.
So I decided to add quad trees to speed up the level rendering process. The level shapes are stored in three different quad trees (one for collidables, one for background and one for foreground shapes). The trees are queried for visible objects, which then get rendered. Works nice and smooth, and the performance goes through the roof, right? Well… not quite.
Since the level shapes can have various opacities, it is important to render them exactly in the order that is specified during level creation (in the Inkscape SVG file). In the triangulation & convex decomposition process the original shapes get split up. It was not a problem during the naive approach — the shape parts were in a list and the original order was preserved. Quad tree on the other hand doesn't necessarily preserve that order, to my great disappointment. It makes sense of course, I just hadn't thought about it until I saw the effect: a few of the level shapes were rendered out of order.
At first I tried to come up with a way to partition the quad tree so that the order would stay correct, but that didn't work too well. In the end I ended up just sorting the queried objects before rendering. That works perfectly, but introduces a new speed hit; the sort. So in all, the supposedly great speed increases of the mighty quad tree turned out to be only a modest gain, since I now need to sort the visible pieces.. Still, I'm confident that the quad trees were worth it, as the levels keep getting bigger and more complex it will surely show more greater effect. And at least I found that enormous bug in the bounding box culling!
Check out a few debug screens below, quad trees are the white lines.
*) I actually found one of the most stupid bugs I've ever done in the bounding box check code. It was actually checking bounds from the world origin (0,0) to the object lower right corner, instead of from the object upper left to lower right! That means that the bounding boxes got very big and only the objects to right and down from the camera view were culled properly.. Ouch.
Once again, I've been improving the platformer engine. I have done a lot of internal restructuring which isn't directly visible on the screen. Remember, this project started as a quick hack testing JBox2D, so the oldest parts of the code were a total mess. Cleaning it up, I implemented modules, that the engine keeps processing. These modules (e.g. GameModule, MenuModule, OptionsMenuModule) are basically separate states and can be ran separately of each other. They also support transitions, so a title screen could fade into the main menu, which could then roll off the screen presenting the actual game. Currently I have an initial loading screen that fades into the game. Yes, all this doesn't sound very exciting (and in reality it isn't), but it makes the code much more cleaner and modular. Hopefully, one my biggest pet peeves — which is writing the menus after the game is complete — will be a more pleasant experience with these module supports in place. I still have some old physics related code there which needs some refactoring love, so there's still work to be done..
I also did the different rendering path thing I was talking about earlier. The best rendering path allows for some neat shader effects, I did initial tests with a distortion shader — it was nice but didn't work with the bloom effect, something I hadn't realised before. I guess I will need to implement somekind of a post processing subsystem, that does the bloom among other effects. Oh well.
Another thing I added is an ingame profiler. While extremely simple, it still presents some very useful data so I can see what part of the game takes most time at runtime. So far the slowest thing is the text rendering. Luckily that won't be a problem, since I don't plan having much text on screen in the game (apart from dialogue, but that can be prerendered into a texture). In the current demo I draw the yellow text with a nice shadowy border around it — that is a very brute force approach which just draws the same string a bunch of times. That's very slow. Also the text rendering could probably be optimized more, should the need arise.
I've been also improving the controller support (yes, the game will support game pads! That's the first time in my [released] games — better late than never, right! ). The basic support was actually added months ago, I just forgot to mention about it earlier. It's still pretty much unusable, since the buttons cannot be assigned: it just uses the first two buttons on the game pad. And that varies per model, a lot. On mine they're positioned logigally, but on another pad they were almost unusable.. So the game needs a controller configuration screen, where the player can assign the actions to the preferred controller buttons. But that's thinking way too much ahead, I need the game first!
One more thing: I made a simple test release of the engine, so that I could collect some data on how it works on different machines. (I mainly test it on two computers, which isn't that much.) Head over to the JavaGaming.org forums and take it for a spin! Hopefully somebody confirms it works on Mac OS X as well.. [Update: Yes it does!] By the way, I will probably take the thing down in some time, since it's still in very early stages and doesn't have any gameplay in it anyways..
That is all this time, stay tuned for more! EDIT: I just realised I had used this very same line to end the previous posting.. Am I really this unoriginal!? Apparently, yes. Yes I am.