Entering Flashlite game contest

22 12 2007

I’ve been interested in entering for Playyoo’s flashlite game contest for a while. I didn’t get an easy answer for myself to actually decide the start of development since I kinda wanted to hold on to my idealism and stick with haXe, but after several considerations I finally threw the idealism-thing away. Especially for the fact that I’ll need to use templates Playyoo has provided to submit a game.

So I’m planning to win the grand prize with a Picross game, and a casual card duel game. I hope I can make it before time, since I’ll need to learn the ropes again with AS2 :) .





haXe and setbacks

16 12 2007

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

4 12 2007

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 ;)