Naturally I will be announcing right here when the game finally gets to the App Store. Stay tuned!

PS. If you’re wondering what’s with the “iJewels” name: the reason is that there was already an app called “JEWELS” at the App Store. I had to pick another name so I went with “iJewels.” “Jewels for iPhone” etc. would not probably have been sufficient.

]]> http://www.mhgames.org/2010/09/ijewels-submitted-for-review/feed/ 0 http://www.mhgames.org/2010/08/iphone-4-testers-wanted/ http://www.mhgames.org/2010/08/iphone-4-testers-wanted/#comments Fri, 13 Aug 2010 08:52:29 +0000 Mika http://www.mhgames.org/?p=437 Do you have a brand new iPhone 4? I’m looking for a couple of people to help testing Jewels for iPhone on the actual iPhone 4 device. I have been working on to make sure that Jewels works also in the iPhone 4 resolution (and yes, I have crisp, pixel perfect high resolution graphics included, as well! ) and while I can test in the simulator just fine, I’m interested in how the game performs on the real device. I think it should run about 50-60 fps (hopefully the max), but it is possible that the high res graphics bring it down, which means more optimizing work for myself..

Unfortunately, I think the testers will need to be in the iPhone Developer Program to be able to install the game on their devices. (Correct me if I’m wrong!) But it doesn’t hurt to ask, right? So, any iPhone devs willing to test it for me? Drop me a comment if you’re interested. If not, I could try to find people on some dev forums. I do have my own iPhone 4 ordered as well, but I’m unsure if I get it before the game is finished..

UPDATE: I did get my own phone, so there is no need for this anymore. It worked quite well, I had to optimize text rendering though. Now it works pretty much 60 fps all the time. The optimizations also benefit older devices (except 3GS, which was running at 60 fps already) so it was time well spent.

I wanted announce that I’ve managed to start working on bringing Jewels to the iDevices (at least for iPhone + iPod touch), even with the taking-care-of-the-baby-business! I’ve only recently started writing it from the grounds up in C++ with some Objective-C (or actually Objective-C++). (If anybody remembers, the original PC-Jewels is written in C#/XNA, while the Android-version is naturally in Java.)

This time I’ll be using OpenGL ES (which, in retrospect, I should have used for the Android-version as well), so iPhone gamers will be getting the smoothest Jewels experience yet! I might even throw in some extra eye candy, just for the heck of it!

I’ve registered to the iPhone developer program, so I can test on the real devices, which is great. I’m aiming on making the game run perfectly on iPhone 3GS (and newer devices) hardware while still keeping it working fairly well on the older HW (like iPhone 3G). These are of course still only estimates, but something of a goal nevertheless. I’m liking the iPhone SDK so far, and even Objective-C isn’t as scary as it looked like before! But as I said, the majority of the code will be in C++. This actually makes a full circle: I had been using C++ for years before I made a switch to Java, and now I’m back in C++ along with learning Objective-C as well! Neat how things turn out.

As to why I’m doing Jewels again (for the third time!), instead of doing something else. Well, it has become a pattern of some sorts for me; while learning a new platform / language / API, I’ve ported Jewels over. The original was simply because I wanted to try coding with XNA. Android-version sprung out from the desire of learning to write for Android. It was a better game as well. And now it is iPhone. I’m learning new stuff and I firmly believe that this will be (again) the best Jewels yet!

Oh, I also noticed (only a few days ago) that there is already a game named JEWELS at the App Store! Just my luck. Any ideas for the name? I think I’ll have to go with iJewels or something like that, which I really didn’t want to do, but I guess there is no option but to change the name…

So there you have it. Hopefully iJewels (still don’t like that!) will gather some following on the iDevices — now I don’t expect it to be a mass hit like on Android, the competition is much tougher, but then again there is nothing to lose in doing the port (or rewrite, actually). I’m gaining some valuable code to reuse in future iPhone projects, even if the game was a flop.

I’ll write something about the porting experience from programmers point of view later; it definitely has been interesting as I have not done any mobile coding before this.

UPDATE on 13th of November:

Now that Jewels has been on the Market for a week, I’d like to share some statistics with you. Turned out that the game is a huge success (ok, it’s mainly because it’s Bewejeled, but interesting still), I had not anticipated this at all! At first I thought it’d break 5000 downloads before the last weekend (the game was released on Thursday). It did, Sunday the downloads were over 16 000. On Monday, it was over 32 000. And now, it’s over 100 000 installs, 92% of them active (i.e. still on users’ phones)!

Jewels is actually the second most popular (free) game in the Market right now with a average rating of 4.5 stars (596 ratings at the moment), only behind a Solitaire-game. Very nice. I’ve actually gotten more comments about Android-Jewels in a week, than I have from all my previous games combined during all these years, wow! So there’s definately market for good Android-games. I’m planning to make something a bit more original next,  so stay tuned.

Of course, it’s not all roses: I’ve released about a dozen updates but still there remains some mysterious bugs that don’t occur in most of the phones, but do in some.. Partly that is because Jewels was not originally writting  for phones (XNA as an environment is way simpler than Android!), and partly because I’ve probably screwed up something (my first Android app, after all). I will definitely try to design the next game to more solid and not so prone to these various bugs and crashes. But one thing bugs me: the Anroid phones are truly different from each other, although in theory the same code should work in most of them, in reality it won’t.. I’ve seeing reports of some really weird crashes that really should not be happening.

Hi, everybody! (“Hi, doctor Nick!” …sorry.)

Little background on today’s topic: When I first heard of the Google Android-platform some years back, I thought it was interesting but never actually expected to see proper devices (i.e. mobile phones) coming to reality. Now that there is several Android phones from a few manufacturers, I’ve been eyeing out the devices with great interest for a while now, I guess closer to a year actually. Waiting for them to arrive here in Finland. And, as you might have guessed already, they have arrived.

The Hero emerges..

So, I got myself a brand new HTC Hero! Obviously, the main interest for me was the prospect of developing software (ok, games) for the Android-platform. Also, it’s darn good phone as well, who would have thought of it? My previous phone was a few years old Nokia, just a basic model with no bells and/or whistles — so this is all new to me.

Why not iPhone, then? Well, there are several reasons I went with Android:

1. The development environment. It’s free, cross-platform and well integrated into Eclipse. Plus I get to write in Java, which I very much prefer over Objective-C.
2. I don’t need a freaking Mac for developing (as if the phone wasn’t expensive enough..)! I can use my old, cruddy PC instead. 
3. Android Market, while still in its early stages, has great potential. Plus not nearly as much competition as in the iPhones App Store (obviously this also means less customers, but things improve when Android-phones gain more market, I hope).

Developing for Android

What this all means, is that I will be making some Android-games in the future. To get myself familiar with the new platform, I chose to port Jewels over to Android. It’s still in very early stages, as I really started working on it only yesterday. It remains to be seen if the standard software accelerated 2d Canvas API is fast enough for my purposes (should be for Jewels), or if I have to go over the OpenGL ES route. If / when I get it completed, I plan on making it available through the Android Market, for free. Actually, at this time it is not even possible to submit paid apps to the Market from Finland, nor it is possible to purchase apps. Hopefully Finland gets the full Market support in the coming months.

After Jewels, anybody up for Steroids³? Just wondering.

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!

Meanwhile, in the programming land…

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:

• First of all, I started using revision control for the source code (+ related resources). Instead of using the familiar Subversion, I decided to try something new and thus chose Git. All in all, this helps me keeping track of the things I do and also serves as a backup in case my computer decides to blow up. Git is nice since you can use it locally, on any directory without a server.
• VBO (Vertex Buffer Object) support. This means storing geometry to the GPU and rendering it in one batch. Basically it means better performance. Using VBOs I could optimize the text rendering by buffering the rendered glyphs into a batch, up until the buffer fills up (or the texture changes). The buffered glyphs are rendered in one go, and the process starts again.
• Particle systems! I started doing a “particle engine” a while back, got it done except for the different emitters. I still need to finish this up: complete the basic point emitter, add more emitters and add the ability to load particle systems from resources (perhaps a YAML or XML file). VBOs are used to render the systems, when supported by the GPU.
• Lighting system improvements. Lights can now have different effects on them, like flickering, fading and pulsating. The effects are defined in a YAML file of properties.
• Player character designs. I’m not sure if this guy ends up being the final character, but might be. I did a quick idle animation for him (need to adjust that a bit, though), I should add a walk cycle next as it’s quite boring to watch now. (The previous animation, test from PolyAnim, did walk!)
• And now for something completely different: Water effects. Yes. This is mostly eye candy (as Box2D doesn’t support buoyancy yet, I think the water is only going to be used for restricting player movements as in the player can’t swim..) so it made no sense to do it at this phase of development. But I did it anyway, I’m childish like that.. The water reflects the scenery above (provided the GPU supports Render-to-texture) and I even wrote a fragment shader to make it all wavy and twirling..

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!

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.

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.

I improved the lighting system to support rotating lights and finally enabled them to be placed to the level in Inkscape (the lights were previously completely randomly generated). To test these new features, I abandoned the ugly mess of a test map I had been using from the start, and built my first “real” level. It’s not too detailed yet (and yes, ugly in some points too!) but at least it’s better than some random polygons. I do plan to expand it to test new features as they get implemented. Check out these screenshots to see the brand new level in action. Disclaimer: All the textures etc. and even the whole style are temporary and not representative of the final game (if I manage to complete it some day), purely because I have not decided on the final style yet! I may opt for more stylished visuals, as in not using “realistic” (photograph based) textures, contrary to what you see in these images. But as I said, I’m not sure yet.

Speaking of new features, I added support for “floor shapes” – shapes that act as a floor but not as a ceiling. That means you can stand on them but jump through them only from below. You can also drop down when needed. These things are so common in platformers, so I had to have them in. Unfortunately I had to restrict them to be straight horizontal lines – “floor lines” like I call them in the code – due to technical difficulties with the Box2D physics. At first I tried doing this with Box2D sensors/contact listener but it seemed like a bad hack and would probably have not worked correctly in some cases, so I deemed it too much trouble and went for a simpler approach. My biggest gripe with Box2D is actually the contact listener, it’s somewhat hard to use it nicely..

One of the things I’ll start coding next is sprites, which will be used in several places: as normal level decoration, level decals, in the background and so forth. Currently everything you see is crafted from polygons, which is wasteful on the resources. In the current test level, at least the mailbox, arrow sign and mushrooms should be sprites.

That is all this time (got to run to the school soon.. :/), stay tuned for more!