Pieces: post-mortem

Wew…

…

…

It has been a LONG while since the last post.

Honestly, I’ve been having hard times to write down this post-mortem.. There were several things coming up after Pieces, including time spent to brainstorm the ’sequel’ of Pieces (on to that later). To sum up Pieces, personally, it was an emotional roller coaster. The award was most flattering and one of the greatest moments of my life.. while on the other side, it picked up various responses including from grief players about the many resemblance to Knytt.

Yeah.. digesting the responses was a mental challenge for me, and I regret being in such a condition of loosing productivity after the release of Pieces. I wasn’t quite prepared about post-release, so I got fed up by the bug fixing until a certain condition was set, which is version 1.3. And I left it be. Until, of course the winner announcements that just.. blew my mind. I always felt that Pieces was a failure.. to have it release in a buggy manner.

But, to balance things up, there were also very encouraging comments. And the most touching moment for me was when someone mapped the whole world as a walkthrough! I was in an awe, and by that moment I knew that some are truly liking it.. a lot. ;_;

So, ok.. nuff with the emotional stuff.. Here are the things that I had in mind during and after development for Pieces:

Things done wrong

1. Next to none beta testing. Yep, you read it right. The competition was about 2 months of time + 10 days of extension. But frankly I only had 1 month and 10 days, since I started it on Feb 1st. Even on the first deadline my game wasn’t quite finished while on the second deadline, I made several last-minute fixing before the closing time. Good thing I was able to update throughout the competition.
2. Left out important credits. This was mostly the cause of grief, Pieces was understood to be inspired by Knytt, but no credit shows either the name of the game nor author of inspiration. Now, in the midst of bug fixing, I set a thought that credits is on the lower part on my TODO list. So I left it be for several weeks and realized I could’ve made some time to write down a decent credit page and cool down the fires.. but I didn’t :(.
3. Put it on NG too early. This is probably related to the commercial side of the game, but I hadn’t knew that it was important to be prepared and made sure everything is 100% OK before submitting to portals, especially NG.

Things done right

1. Invested time on coding a map editor. During prototype, I instantly knew that the game will emphasize on map exploring for it’s gameplay. So I coded a map editor in haXe with SWHX, which allows me to save and load map data into files, and also export the whole world as a Map class in AS3, ready to compile.
2. A simple and solid game design from the start. I was satisfied with the core mechanics and design everything around it. The amount and types of skills varied several times, and it depended largely on how quick I can code the basics of it. If I felt it’s too quirky or difficult, I quickly try something else.

Several technical-related issues

I had pretty much everything working really good. Map loading was surprisingly fast, and the collisions were simple and working the way I envisioned. Except for one, the progress saving system which uses LSO’s (Local Shared Object).

There were several reports and complaints about having the blue herb and after a load, it was gone, etc. I’m sure it’s something to do with LSO but wasn’t quite sure how it happened and why. Currently I’m guessing it’s a file size issue. The game needed N amount of bytes but the players computer stored less thus cropping several data. What bugs me the most is how I couldn’t fix it because I can’t make it happen in my system.

Performance

I think Pieces isn’t everyones game. I found several loving it, and several hating it. I think it’s probably due to how I broke several fundamental game culture, like not allowing Proo to be able to jump at first, and the awkward way of getting skills. Plus, there were no monsters to jump on or kill.. :D.

Several stats:

• Kongregate. Submitted on March 26th, 2008. 47,338 plays, 3668 ratings (avg score: 3.39 of 5.0), favorited 300 times.
• Nonoba. Submitted on May 15th, 2008. 4.984 plays, 128 ratings (avg score: 3.5 of 5.0), favorited 44 times.
• Newgrounds. Submitted on March 24th, 2008. 1,136 plays, 267 ratings (avg score: 3.23 of 5.0), favorited 12 times.
• Mochibot statistics.

Got “Best Use of Theme”

Last monday JIG announced the results for CGDC5, and (drums rolling) Pieces didn’t win but instead got the prize for “Best Use of Theme”. YAY!

As mentioned in the comments, I really really really didn’t expect to win anything, mostly due to how buggy the game was on release. But I just got an email from Jay saying that I had the most updates, or err.. “upgrades” *winkwink*, on my game than the rest of the contestants and that adds my score on the theme category. I’m not sure if that’s a good idea to do for any other competition :p. But I’m happy, and very honored.

Feedbacks were great, and even for version 1.3 I had the credits changed mentioning my thanks to the JIG audience that literally beta test my game. How embarrassing, they’re supposed to just play not beta test :(.

Congrats to the other contestants (even the ones who didn’t get to the top 10), all of the games were great!

Detour: entering JIG’s 5th Game Design Competition

Yup! A ‘quick’ detour.

I wasn’t intrigued to enter at first, I never thought I had any good original ideas to come up with. But after reading about the benefits of entering (like your game gets submitted automatically for MochiAds “Be a RockStar” gamedev competition, and the possibilities of sponsorships, plus the use of MochiAds), it got me hooked. So I took the time to do several brainstorms, and had a somewhat good concept.

It’s called “Pieces”, and it’s a platformer. You play as Proo, this little character (girl?) that landcrashed to this strange place. She lost her memories about everything, even her bodywork skills (running, jumping, etc). Your goal as player is to guide her to recollect pieces of her memories, skills and craft to get her back home. The somewhat unique aspect of the game is how she learns (upgrade) her skill, which is done by doing 2 things in order:

1. find objects that interests Proo (create curiosity/interest).
2. find creatures that indirectly tell Proo how things are done (watch role-model).

The mechanics of getting these status is quite simple, as soon as Proo enters a map with either one point (interest or role-model) it automatically gains the corresponding status.

To make it more clear, here’s a simple example of how things would work (and will be in the tutorial mode):

You start with Proo being immobile, sitting and wondering what to do. Then Mr.Tutorial drops a food beside her only several steps away. Proo has the food in her interest slot, but you can’t command her to move her to the food. What to do? Proo needs a role-model, so Mr.Tutorial lets a creature come in running from side-to-side, probably stopping for several moments before finally it move along. By that time, Proo gains a new skill, you get a notice how to use the cursor keys to move her.

That’s pretty much the base of how the game works. Proo will encounter a certain map where she needs to jump and the same thing start over, ‘jump’ is in her interest slot and she needs to find a role model to help her understand how to jump. The placements and terrain of the map will be the puzzle and exploration is essential in the game. Monsters and obstacles? Maybe I might add them, but currently I imagine this game as ‘very peaceful’, so no death feature for Proo, I guess.

I’ll be programming this in AS3.0, using flex2SDK. One of the things I took consideration is that I’ll need to add external codes from JIG and MochiAds to be eligible to enter competition. But I’m sure there will a place for haXe coding as I’m planning to do the map editor in haXe+swhx.

Got “pick of the day” :)

Yesterday, David from Playyoo commented on my PicrossLite post-mortem article. I was surprised to find anyone commenting, so I looked it up and it turns out to be a very useful comment :). He gave me some tips regarding technical and gameplay aspects to improve PicrossLite. Hmm.. it made me feel like doing more flashlite games now :D. As if it wasn’t enough, PicrossLite got to be in Playyoo’s pick of the day :D. This is really encouraging. Thanks David!

 

Working on new title: MercOps

My plans for current game for sponsorship is to avoid real-time fast-paced action game :D. A little disapointed with SoM, yes.. but mostly just wanted to try a new genre. Strategies, especially tactical strategy, fascinates me. Titles like XCOM:UFO Defense and Jagged Alliance are the most favorable games. They don’t do those games anymore, so I’m determined to bring it up in flash, but more casual.

MercOps is a working title, and is basically a tactical strategy. It’s more like Jagged by theme and mechanics, although not as complex as Jagged. I planned to have it in isometric view and you start out with a set of mercs. All in default stats. Mercs will gain exp and level up automatically depending on what skill they mostly use. Certain skills will add more to exp, like ‘accuracy’ and kills. If a merc dies, you can recruit new ones after a mission ends. The goal of each mission is simple, eliminate all opposing forces on the map. Once cleared, you’ll be shown a screen of statistics and options, like recruiting new mercs and save/load. I’m not sure if money will be involved in recruiting (if it does then I should plot how will the team get money). I also haven’t laid out all possible weapons and items (armor? grenades? etc) yet, although I planned to start with a very few and maybe add more for the sequel. Yeah, I think it’s best to design for a series.. like say 3 - 5. Adding more detail and most importantly, the feature to keep mercs from previous series :).

Jagged Alliance 2: WildFire, courtesy of MobyGames.com

Development will start with prototyping, and learning from SoM, I’ll make sure to ‘prototype’ everything: including screen/GUI flow and transitions so it’s already in a ready-to-complete-by-producing-art-assets state. Doing art in between code and design can slow things down. I hope I’ll manage to be persistent this time. So currently I’m doing placeholder art and will start coding shortly. I’ll be using flex for this project. I found haXe a bit troublesome if you’re going to use 3rd party API (from portals or mochiads/mochibot). Plus the weirdness in exclusively needing flashplayer 9.047.0 when outputting flash9 in haXe (I managed to find several players discouraged with the wrong flashplayer version error in SoM). I think flex doesn’t have that, plus you can easily make a preloader on a single swf and it’s AS3 :):):).

It’s already mid-January and I’m way out of schedule. I planned to release something by February and now, I think I won’t have the time :(. But just making something vs. making something you like and worth playing is very different and that’s my base for working on MercOps. I hope I learn my mistakes from SoM and produce a worth playing game. Till then :).

Picross Lite: post-mortem

Ok, it has been a week from the release to playyoo. So far?.. Not good :D:D:D..

There was one bug that the owner of playyoo (David) caught several hours after the release. Good thing it was a very minor one, so no sweat. But then, after that.. it seems pretty much low and even almost no attention at all. I figured maybe the site hasn’t been picking up traffic lately, due to several things (I didn’t feel the hype during that week, as several other games released before and after PicrossLite had little to no attention too).

One major flaw for me was, I didn’t have the hardware to test it live through mobile :D! How’s that for being a serious flashlite game developer :D:D:D. I couldn’t encourage other players to beat my score. And there was no scores up till several days, and very few previews.. not to mention below 10 downloads. I guess people might just see the page and went off to another seeing no one has participate on scoring (it might still have errors, or it’s just impossible to get a decent score.. is probably what they think).

Another theory is, picross is just too unique. Especially for the mobile users. If you look at other games, the ones making noise are the very very simple and familiar ones. Like match blocks, sokoban, more match blocks, etc.

And to wrap it up, I must say, targeting FlashLite 2.x might surely be another factor of low downloads. Flashlite 1.1 phones are more populated than FlashLite 2.x.. so I just realized I’ve committed to my own failure :D:D:D.

Oh well.. not my luck this time. But still.. I’m pretty determined to get into this market. Mobile is huge. Doesn’t sound like it, but it is. If you can’t win the competition space, there is still room for commercial ones :). Just be optimistic, and keep producing :). Oh, I’m definitely be re-releasing  PicrossLite for commercial, probably add more puzzles and the ability to store progress. Probably might call it, “PicrossLiteDeluxe” :D.

Picross Lite

I’m not sure for how long I completed this FlashLite game. But I’m sure it’s pretty much longer than it should for a simple game like Picross (ehm.. like ~2.5 weeks?). The main problem I had for developing this game was that I felt sorta reluctant to go back to previous versions of ActionScript. As you might know, FlashLite only supports at the most AS2 with Flashlite 2.x and Flashlite 3. While Flashlite 1.1 uses AS1.

I was sure I won’t touch AS1 so Flashlite 1.1 was not my venue. But coding in AS2, from having the pleasure of AS3, was also a setback for me. Mentally, I guess. I’m such a stupid idealistic perfectionist, so I had to take the time to chew AS2 and familiarize with the API.

Since I’m relearning something, I thought I’d pick a game that won’t need too many effort for programming, but know that it’s fun to play and also unique. Well, at least unique in Playyoo.com as this is an attempt to enter their FlashLite gamedev competition. Deadline is Feb 15th 2008, and they’ll be judging by how many downloads your game is going to make. Quite frankly, having a game submitted earlier makes it have the advantage of having more downloads. Being optimistic, I hope my game could be in the top 20. I’m sure it won’t beat the #1 game which is a simple block-matching game (ala tetris, but with 2 blocks only) as it has more than 100 downloads already.

Basically the game is a simple picross game, with a total of 30 puzzles in it. The board is static with 8 columns and 9 rows. I kinda realized I could make it start with something like 5 x 5 for the easy ones, and 6 x 7 for medium and then 8 x 9 for hard, but it was too late. I’ll have to modify the editor (later on that ;)) and modify a lot of things, so I’ll just save it for a ‘deluxe’ release. Clues are also ’static’ with a maximum of 3 layers deep per side (3 for the rows and 3 for the columns). Which means, they’ll be only a maximum of 3 and a minimum of 0 group dots. So the level distribution is, “easy” with 1 layer of clues, “medium” with 2 layers, and “hard” with 3 layers.

Each puzzle you start with will be timed, and each puzzle has an ideal time hidden that’s used to calculate the time bonus score. Basic scores are static where 100 is for the easy puzzles, 200 for medium and 300 for hard. Total score is basic score + time bonus score. If you can solve a puzzle sooner than ideal time, you get big bonus of score, or else you get a minimum of 10 for time bonus score. Score submitting is done when you decide to quit a game session. And you can quit anytime, no pressure involved. Although not having all puzzles solved means small scores :).

Since playyoo provides a template FLA file to use for submission, I was definite to not use haXe this time :). But it turns out not all that bad, especially I eventually implemented the ‘framework’ I had built for myself for SoM to PicrossLite in AS2. Not exactly the same, but had reminiscence of it. I also had it all in classes so FLA file for the game frame was completely clean with a single line (not including #import ;)). I’m pretty satisfied with the process.

The editor, on the other hand, was coded in haXe as I wanted to use ScreenweaverHX for load and save feature. It was a simple editor, merely as long as it functions by the visuals but not too degrading :). Luckily I had made several UI classes for BarnyardTactics (this frozen multiplayer tactics game project in haXe pre-SoM) so no problem with UI. Save and load was also simple, I just wanted the editor to be able to parse and ’serialize’ the level pattern which then is placed in a file. Once there, I could just copy and paste in to the AS2 code, with little modifications (added an expression to insert the pattern to an array). I know, needs a LOT of improvements, but at least making the levels was really fun :).

All in all, I came to discover it wasn’t that bad coding in AS2. It had OOP already so I wasn’t feeling to much alienated, plus there are several advantages (although it could be also disadvantages by code-aspect) where you can setup the UI and place MCs or TextFields with instance names and just access it directly from code, compared to building everything by code. It does somewhat speed up things. Well if we’re talking about speed in development, you can actually speed code in Flash if you want to. Emanuele Feronato has several tutorials on it. But me, again, I’m a stupid idealistic perfectionist and I can’t let my code be so ‘hacky’ like that :).. Not that having ‘hacky’ code is bad.. it depends on yourself, I’m sure (the ability to decipher your own code when a bug is detected).

I hope I get good response for this, and I’m sure I’ll be looking closely on this (mobile) market. I’m planning to do a sponsorship game this month and after that, hopefully work on several flashlite games and monetize them as well. Mobile market looks stabil and closures are emerging (this years IGF includes mobile categories). Plus, it’s challenging developing for a gadget, the constraints of screen dimension and user inputs. It has a tingling feeling :D.

Preview the game from playyoo.com, or from this direct link.
If you have a flashlite 2.x enabled phone, I’ll be very thankful for downloading my game. Please give any comments if you also will :). Oh, and try shooting for the highest score ;).

Entering Flashlite game contest

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

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