SoM: completed.

SoM is done. Finally completed last Monday (2007-11-26). I decided to go through an ‘agency’ so I could still focus on game production, whether it’s updating SoM (for bugs or implementing publisher backend stuff like highscores, preloader, etc etc) or working on the new project. If you’re interested in making games in flash and monetizing it through sponsorship, maybe you might want to consider FlashGameLicense. That’s where I put SoM in, and it’s currently making.. 6 bids so far. Very convenient system, kudos to my agent Adam Schroeder!

On to the next project then. I have several options to decide. There are 3 ideas currently.

1. Platformer game. Idea is inspired heavily by Knytt Stories. Large world divided into 5 realms, relaxing linear game with a charming story. Working title: “The Frog Prince”.
2. Stealth game. Something like SplinterCell but in a different theme and situation. Top-down view, escalating levels, probably as much as SoM (50 levels). Working title: “Escape Prison”.
3. Platformer game with gravitation modifier. The idea first came from a level in Megaman X8. A platformer that has special nodes to rotate the level and gravitation.

I got more ideas coming but these are the ones I see fit to do with my timeframe, and also my mood . I’ll need to do some research and minor prototyping to decide which to go for full production.

But before that’s going to happen, there are several things I might need to do first. For one, writing a tutorial in haXe about making a simple game, this is for the GDIEzine request for articles that’s due this month. :D:D.. I’d also like to write about the post-mortem of SoM, from start to end, the ups and downs. So, I guess.. till the next post!

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.

CRUNCH TIME!

Ow man.. it’s Monday already.

I’ve already put up the game for bid several days ago, got pretty good response and last bid value wasn’t bad although it’ll be very sweet if it is a little bit higher. As for that, I’m currently in super duper ultra crunch time as I promised my agent that I’ll have all the features for release done today, which I’m sure with the release the bids should go up .

Stuff I need to do:

1. Finish the tutorial system. I’m still keeping the instructions page, but I’m implementing a tutorial system as well. It’s so frustrating to design a tutorial system (maybe due to the deadline too), but I’m sure this is a plus if it’s all done.
2. Sound fx and fixing the SoundManager. Last time, my SoundManager gave some hell of anomalies to the game so I’ve cut it out for a while. Oh man.. and the soundfx.. I haven’t inventories which sounds I want to put..
3. Mission backgrounds. I’ve got 1 already finalized.. I have 5 more to do.. doh!

I think I’ve been too optimistic and over-estimated the release date.. hmm.. that’s 1 valuable lesson. If possible, hold back the urge of throwing a nearly released version of the game before actually releasing it. You won’t know what trouble you might encounter later!

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.