haXe and setbacks

Publishing SoM gave me an idea what the requirements are for having something released on a public space commercially. haXe is a really nice language and I’m very pleased to have done SoM on it, but several feedbacks just got me thinking.

No easy way coding preloaders in a single file (esp. for flash9 API).
Portals require you to submit a single file for you game, and although they might not require a preloading mechanism, mostly the players do and demand a feedback from the game to inform them whether it’s loading or not and for how much long to wait. The usual way of having preloaders (in AS2 at least) is with putting at least 2 frames on the main timeline, where the first is stopped and looped while monitoring download progress using bytesLoaded and bytesTotal. I’m not quite sure how this is done in AS3 (Flash CS3), which I believe it could be done in the same way but wouldn’t say is elegant, but I’m sure Flex has it ‘installed’ by default. For haXe?.. I think it’s possible to have one targeted for the < flash9 API (flash6, flash7 and flash8, these are equivalent to AS2 API), but beyond that.. no can do for the time of this writing.

Hard to integrate with portal specific code.
I wanted to submit SoM to Kongregate and found that you need to download a component from Kong to have your game interact with the Kong system (statistics and highscores). I wasn’t sure if it was possible to add the codes to the swf for swf-lib in haXe as it is in flash8. I think it might be possible, but I just lost interest in researching . Luckily the code for highscores on armorbot.com was easy to port to haXe as it was just several lines of code.

haXe is still my first choice to go for any day coding for swf content, but on several occasions especially when you need your work to ’socialize’, then I might say go with the crowd (unless someday haXe has half of flash’s market :p).

SoM: post-mortem

Sentinels of Mijil finally got picked up by sponsors, namely Hallpass and ArmorGames as a collaborated/joint of sponsorship (which means each portal invested half of the total value). It’s been great working with these 2 publishers, they were professional and had clear instructions on changes or details I need to modify as part of the sponsorship deal. You can check it out here.

Besides uploading it in Hallpass, I had it up at NewGrounds and also UGOPlayer. The response was pretty good overall, despite several players disappointed with the non-existence of a preloader. Well.. not so good then, I guess, if you’d say having a score below 3.5 in NG means definitely not worth playing, plus the only 12 reviews and 1,548 views. I didn’t get the mood to put it in Kongregate which could say differently, I know I should.. you can’t get too much of feedback, can you .

The feedback was always worth reviewing. Some mentioned features that at first I had plans to implement but later discarded. And those were the critical ones, like meters and indicators especially for the heatup-burning-cooldown stat for weapons. The beta testers hadn’t mentioned anything about it, as it was natural for them without these meters, I guess. But you’d never know how much diverse your players will be so, it’s always good to make sure. While personally, adding them means more code and I was just too frustrated handling the collision algo bit to make it as tight as possible. I know, that was just an excuse.

The enemy design was kinda faulty, especially with spawners. It seems several players had the lag time due to not responding to the hidden priorities of killing certain type of enemies. Having more than 60 enemies all at once in a screen is too much for AVM2 to handle still, I could’ve thought of something better, but then again, too lazy or just too occupied with thinking on the performance stuff. Players wouldn’t like to experience the lag, so a smooth play is very important. If the platform can’t handle a certain amount of performance need from your game, then it’s best to modify the design too keep it out of lag.

I’ll certainly keep these points in mind for the next game, or probably a sequel on SoM

Statics are bad

I never knew this, till just now. After reading a new blog entry from Nicolas, the author of haXe, about optimizing, he explains that calling static functions are 10x SLOWER than methods.

What?!?! Oh man, I’ve got ALL of my managers in statics, dude! ScreenManager, ParticleManager, MissionManager, even ProjectileManager and CollisionManager!!.. Well, fancy that.. in the moment of being frustrated with crunch time, I just had to read that entry. I’m itching to tweak on the CollisionManager as there are several moments of FPS drop. Very subtle actually, but after several plays a ‘veteran’ might notice it.

I guess I’ll do it as an update after the release.

Grid spatial indexing

The project has gone through a lot of progress in the past 3 weeks. For one thing, the title now is called ‘Sentinels of Mijil’ and has gone through several beta testing sessions and a lot of bug fixing. It’s almost two months since the initial code from scratch… and not so long enough, it’ll be A LIVE!!!…

… erm … i mean, ONLINE.

One of the aspects I took careful thought through the game is how the collision detection is done. I wanted a fast-paced action shooter with swarming enemies emerging while you get to pop em with explosion galore. So, definitely a good collision detection is key.

I’ve read several articles about it, and concluded grid spatial indexing is best for the game due to the fact that all object collisions are calculated through hitboxes and there are only 2 sizes of hitbox, plus grids are easier to do . I had to admit I was very intrigued to use quadtrees, but I felt I needed something quick to code and that works well enough.

Grid spatial indexing is, well of course, a method of spatial indexing. In plain English, this means grouping visual information and managing them so it’s easy to retrieve the data and do whatever you like to it. In the topic of collision detection, spatial indexing is a way to sort all the objects based on visual information (coordinates, dimension, etc) from grids and calculate only the most possible group of objects that are expected to collide. Or plainly saying, just calculate objects that are near (in the same grid) and forget the others .

Comparing to the brute-force method I mentioned earlier, spatial indexing totally rocks. Just think about it, with brute-force (or some like to call it pairwise) method you need to calculate as much as the square amount of collidable objects. For example, if you have 100 objects to collide, for every tick of game loop you need to calculate as much as 100 x 100 = 10,000 collisions! That, my friend, is a lot of processing waste. Not to mention we’re using the Flash platform here (although the AVM2 is very fast now, pairwise is still an overkill). I’ve tried it, and it is as what it’s expected: a very big drop in FPS.

Implementation is quite easy, here are my steps:

1. Setup the grids at start. Of how many grids is enough for your project really depends on how big is the game window, and how big objects of collision are generally. For instance, in SoM the game window is set to 500 x 500. Hitboxes of enemy units and the size of players hitbox is approximately 20 pixels so it’s rather obvious to have 25 rows and 25 columns of grids.
2. Create an array to place grid ids of grids with objects in it, this way you’ll only loop through grids in that array and not all grids. Let’s call the array CalculateGrids.
3. During game tick, each object needs to register or unregister their current grid id to the CalculateGrids array. Knowing which grid the object is in is quite easy, by dividing the objects coordinates with the grid dimension will give you fast results.
4. Then it’s off to calculate the actual collision, or what it’s usually called as the narrow-phase of collision detection (while spatial indexing is usually associated as the broad-phase of collision detection). There are a lot of popular methods in narrow-phase, like Axis-Aligned Bounding Box (AABB) and Separating Axis Theorem (SAT), but since the collision behaviors are very simple and nothing fancy, I think hitTestObject is quite enough.

The results are pretty much satisfying. With a swarm of 100 objects at once, no fps drop occurred. It start dropping when 400 – 500 objects are running the same time, while with pairwise since 100 it has dropped. This wasn’t an ideal situation although it can be acceptable by tweaking with the gameplay. There are several thoughts in optimizing, like:

1. Replace the narrow-phase method to SAT. Sometimes I wonder if hitTestObject is actually making the lag and is that bad.
2. Work on the register and unregister of CalculateGrids array. This can also be a problem as registering and unregistering can be very frequent.
3. Use quadtrees.

For now I don’t have any code to share as I’m still focusing on releasing the game, but I might whip up one soon. I hope this is useful.