Starcom Postmortem

Updated 6/18/2009

This is the Postmortem blog post for Starcom.


Starcom is a single-player Flash game where the player commands a starship from a top-down perspective exploring the galaxy and fighting off an encroaching enemy invasion force.

This was the second Flash game I ever wrote and was an extraordinarily ambitious project. I conservatively estimate the game took 500 hours to make, including coding, game design, artwork, sound and playtesting.

I wrote this postmortem document to help me recognize what I did right and what mistakes I could avoid if and when I decide to do a sequel.

Game Design

The Concept

My original conception of Starcom was based on an old DOS game I played as a teenager called “Starflight.” In Starflight, you command a starship in a Star Trek-like universe, meeting and battling aliens, exploring planets, and collecting cool stuff and artifacts. It was a remarkably detailed universe given the fact that it fit on a couple of 5 1/4” floppy disks.

At the same time, I had been watching the new Battlestar Galactica series. I wanted to capture some of the intensity of the epic space battles in the game.

Game flow

In a space-based game, players expect the universe to be far more open than in, say, a dungeon. In a dungeon it is perfectly natural to have to explore one level before moving onto the next, and so forth, in a linear fashion.

I originally didn’t want the game to be linear. I wanted the player to be able to explore a vast Galaxy of generated systems looking for cool stuff. I even had a random system generator. But playtesters complained about the lack of direction. With no storyline, they felt no compulsion to keep playing. Or even any hint that there was cool stuff for them to see and acquire in distant systems. This is probably why there are so few non-linear single-player games. So I abandoned the idea of an open universe in favor of a mostly linear plot.

In space, constraining player movement is difficult. The first mission of Starcom forces the player to learn the basics before acquiring the Nexus Navigator and leaving the Star System. But I was forced to use a number of contrivances to keep the player moving through the story in a linear fashion. The main trick was having new Warp Nexii appear only after the player has completed certain missions.

A lot of players have requested a bigger universe to explore. Perhaps in a sequel I will try to incorporate more freedom to go “off map” while still providing some direction for a linear narrative.


The question “How should a spaceship control in a top-down video game?” is surprisingly tricky. Most Flash games restrict movement to the screen and use a cardinal movement system, i.e., you push right and your ship moves right on the screen, which wouldn’t work well at all for this game. The first version of Starcom used a control scheme very similar to this one, but where your direction of movement was always in the direction your ship faced. Easier to control, but playtesters found it too “car-like”. I tried various momentum conservation techniques (including no “space resistance,” which while physically more accurate wasn’t as intuitive) before settling on the version in the game now.

A related issue that I hadn’t foreseen was the problem of speed. Players want to go fast. It feels more exciting and it allows you to move between objectives quickly. The problem is, the view port is 500 pixels wide with your ship in the center. You have 250 pixels between you and the edge of the screen. If you’re moving fast and the enemy is heading straight toward you, he may have passed you before you’ve had time to react.

Speaking of speed, how do you let players know that they’re moving at all? Realistically, of course, you don’t. But that’s no fun. So you have to provide reference points to show movement. Other ships work well, as do celestial bodies, but if none of those are on screen, you need something to “feel” the movement. A scrolling background doesn’t work well in space (I tried it using a star field). Expanding on a technique I saw in another game where there were three layers of stars moving at different speeds, I used a random scattering of stars with different alpha values, which were shifted as the player moved by an amount proportional to their alpha, so faint stars moved more slowly and appeared farther away.

Given post-release feedback, there were still a significant number of players who weren’t happy with the handling of the ship. A possible solution for a sequel would be to give players a choice of ships, each of which handles differently, and perhaps has different capabilities increasing replayability.

In addition, I should have offered players the option of configuring their keyboard controls. The default control scheme works well for right handers, but some of the keys are poorly positioned for left handers (e.g., Turbo Thrust and Jump).


Probably the second biggest complaint after “this game is too short” was the lack of a good map of the universe. Players found it too easy to get lost. I initially planned on adding a star map, but this feature was never fully implemented. Definitely if a sequel is going to be larger, than a good mapping system will be essential.

Likewise, players couldn’t remember which Nexus went where. The game should have had some way of letting players know where a Nexus they’ve already entered leads to.


To be written…

Inventory Management

The inventory system was re-written from scratch once, but it’s still something I’m not happy with.  Inventory items were sort of a tacked-on feature.  Part of the problem was that conceptually, I imagined all game items (things that could be picked-up, bought and added to the ship) could be handled more or less the same way, with subclasses handling special cases.  It turned out to be a lot more complicated than that.

Here are some issues that arose with my various attempts at an inventory/item management system:

  • How should inventory manager be laid out visually?  There’s a lot of information to display: what items the player has installed, what items the player has in cargo, items in Starbase, the item description, its sell price, the actions that can be taken on the item, any stats, any stat modifiers, etc.
  • Many items modify the behavior of other items.  For example, a yield maximizer changes the performance of the missile weapon system.  There are lots of different cases here.  Where is this information stored? When displaying stats on an item, should its modifiers be displayed as well?  What about when the item isn’t installed?  Or even bought?
  • How are unidentified items handled?
  • Does every item in the game have a unique identifier?
  • Can there be multiple instances of the same item, or should every item have a unique identifier?
  • How do you represent “where” an item is?  E.g., installed on the player ship, in the player’s cargo, in the Starbase store, floating around in space somewhere, or in some abstract enemy treasure trove waiting to “drop”.

Inventory management is an issue that is likely to be more complicated in a sequel and I’ll need to have a much better plan for handling it if I don’t want it to be headache.

Upgrade Balancing

Balancing the various weapons and armaments was more or less an exercise in trial-and-error that I don’t think came out that well. The Havoc system is underpowered and shields charge so slowly that players found little use in upgrading them.

I think it is only the short length of the game that kept players from complaining about component upgrade disparities.

In a sequel, I’ll need a better system for measuring the relative value of each upgrade.


Developing for Flash

A Flash game is a game that can be run by Adobe’s Flash Player. It’s interpreted (not compiled) so it isn’t nearly as fast as a native application. On the other hand, Flash is ubiquitous, and more importantly, a Flash game doesn’t require any additional downloads. If someone goes to a web page with your game on it, they can play it as soon as it finishes loading.

This is the number one reason to develop a game in Flash– you can get massive exposure very easily, and consequently lots of feedback. If you develop a stand-alone download game, unless it’s a hit you probably won’t get very many plays. Maybe a few hundred, including friends. So you won’t get a lot of feedback. Without feedback, you can’t learn what you’re doing right and what you’re doing wrong. Which makes it harder to develop a hit game.

Flash’s Limitations

But there are problems with developing in Flash. One of which is monetization, which I’ll discuss later. Some of the technical limitations:

  • If you’re making a Flash game, you probably want to have it distributed to portals. Which means it should be 700×500 pixels or smaller. That’s a lower resolution than Diablo II.
  • Flash runs much slower than native code, even slower than Java (which is interpreted byte code). You can’t do all the fancy graphics that standalone games from five years ago did. Flash also can’t use video card acceleration. (This might be a good thing, since video card capabilities vary wildly, and if developers started writing Flash games assuming GPU acceleration, a lot of people would see Flash games that ran like a slide show.)
  • Flash games are expected to be casual, quick loading affairs. 1-3MB is typical. Starcom is a bit hefty. It’s 3 MB without any music. All three music tracks add up 5MB. Since 8MB is way too big for a Flash game, I embedded only the first track. There are triggers in game that tell the game to download additional tracks when required, so they don’t slow down the game load time.

How do you develop a Flash game? Flash games are written in some version of Actionscript. I’m only familiar with the latest version, AS3. And what do you use to write and compile Actionscript?

One option is to use Flash, Adobe’s design tool. Lots of people go this route, especially people coming from a design background. Personally, I don’t think it’s a good method. Flash may be great for designing “movieclips” (timeline based animations), but it’s a terrible coding environment. The movie metaphor doesn’t map well to organizing code. If you’re coming from a programming background like me, you may be lost as to where to put your code and classes.

A second option is to make what is called a “pure Actionscript” application. You can do this using a third party IDE like FlashDevelop, using either Flash or the Flex SDK to compile. You could theoretically write all your AS in notepad.

A third option is to use Flex. What is Flex? That’s a little confusing. Flex Builder is the name of Adobe’s development tool, which can be used with or without the “Flex.” Flex is a collection of components and a markup language called “MXML” designed to make creating Rich Internet Applications easier. Because Flex contains a lot of great UI tools, such as lists, layout containers, dialog boxes, etc., I decided to try to use Flex for Starcom’s UI.

Programming in Flex

I should mention first that Flex pre-compiles MXML into Actionscript. So if you’re using MXML, you still are doing everything in AS3, but there’s an additional layer of abstraction on top where you set up the application layout and components.

It turns out that this layer of abstraction can be confusing. I wasted a huge chunk of time trying to understand the nuances of Flex components.

For example, normally when you create an object in Actionscript, you call the class’s constructor and get an object back, ready to roll. With Flex components, you get an object back, but it may not be completely ready to use. Flex uses something called “deferred instantiation” where complex components are assembled and laid out during free CPU cycles. Maybe it’s ready right away, maybe in a little while. So you need to attach an event listener for when the object is really ready.

This is a minor inconvenience, but more importantly, creates scenarios that are very unpredictable. In a game, it’s not uncommon to be using the CPU heavily most of the time. One bug I spent several days working on was the mission update dialog box, which informs players about various in game events. The dialog is non-modal, meaning the game play continues while it’s on screen. Sometimes this dialog would show up instantly, sometimes after a few seconds, and sometimes wouldn’t show up at all until the game was paused. The reason, I eventually surmised, was that Flash wasn’t giving it enough priority. “This is a deferred instantiation object. It’s not critical. I’ll finish it later.” Flash was procrastinating like a programmer. Since in an action game it’s always crunch time, the object often never got finished. (Incidentally, in Flex Builder you can suspend execution of an application while in debug mode to investigate what all the objects are up to. Theoretically, nothing executes while the application is suspended. Bizarrely, I discovered that if I put a trace statement in one of these missing dialogs, it would report that it finished building sometime after the game was suspended.)

I’m not sure if I would recommend using Flex for game development. It is very nice to be able to layout the UI like a web page and customize pre-built components to cover the various interfaces. But I don’t think I’m alone in my difficulty to understand the vagaries of Flex’s layout system.

Game Architecture

Overall I’m happy with how I chose to structure the code. In any large project there are inevitably going to be code decisions you regret down the road, but Starcom didn’t turn out to be a disorganized mess of hacks. There was one ground-up re-write a few weeks after I started working on it, and a few small re-factorings.

Starcom’s Overall Architecture:

  • The main entry point into a Flex application is an MXML component that subclasses the mx:Application component (unlike an Actionscript application where the main entry point is a subclass of Sprite). So Starcom’s main application class is a light-weight component that handles the preloader, site lock detection, opening the game menu dialog and adding a game window component.
  • The game window component is what you spend most of the game looking at. It consists of a ViewPort object (the top down view of space and your space ship), a ScannerView object (the mini-map/radar), a console list object (the status of various key ship components) and some menu controls.
  • A game is loaded from XML, either the default “new game xml” or the xml from a previously saved game (see below for the implications of using this system).
  • The game object is a container for everything in the game. I made a concerted effort to keep this class from growing too large, but functionality did have a tendency to find its way in there.
  • When the game was playing, the game’s enterFrame handler executes the following major actions:
    • Clear the particle layer (a single bitmap layer where particle effects such as sparks and explosions are drawn)
    • Call the update method on the player entity, which handles not only moving the ship, but updating all components such as weapons, shields, jump charge, etc.
    • Tells the map to update entities near the player. (See comments on the map class below)
    • Updates particles
    • Fade the “smoke” layer using a combination of blurFilter & colorTransform.
  • When a player first enters a star system, a map object is created that represents the two dimensional space. This map is partitioned into a grid of nodes, which help with both broad phase collision detection (deciding if two objects can interact) and allowing the game to only update entities near the player. This meant that a star system could have a very large number of enemies and objects without dragging the game to a crawl.
  • In-game help, missions and achievements are handled with an action/trigger system:
  • A trigger manager maintains a list of active triggers. Every frame, each trigger’s isMet() method is called. If it returns true, each of the triggers’ action objects’ execute() method is called.
  • A trigger can look at any of the public properties of the game object, including sub-objects like the map, the player’s inventory, etc. This allowed great flexibility in what triggers I created.
  • A downside of this system is that every active trigger needed to be called every frame to see if it’s met. Since the isMet condition was generally a fairly simple boolean, this didn’t impact performance too much.

While I say I was happy with the game architecture, there are always improvements that can be made and if I rewrite the engine I’d like to correct some of these mistakes.

Too Much Inheritance

I made the classic beginner object oriented mistake of overusing inheritance. For example, the basic game entity has only the properties that all game entities share, such as position, radius, owner, velocity, etc. A slightly more complex entity, called a physical entity allows for collision detection (there’s overhead for maintaining an entity’s map node, so I didn’t want unhittable objects burdened with this feature). While another entity is the projectile, a non-physical entity that has properties and methods for dealing damage. Then came the missile entity– a projectile that could be shot down. AS3 doesn’t support multiple inheritance, so I had an awkward situation where I created a physical entity for the missile itself then a projectile entity representing the warhead to deliver damage.

Instead, I should have either used composition or interfaces to keep the game entity tree small.

Game Save & Load

Most Flash games have fairly anemic save & load functionality, if they implement it at all. Often, they simply store the last level you completed.

Starcom needed a real save system, since players were exploring a large and interconnected universe while modifying their ship. The game needed to save what map they were on, their ships position, what equipment they add, which enemies had been killed, which missions they had and had not completed, etc. At the same time, I didn’t want to save everything, such as the position of every bullet and particle active.

My solution was to only allow the player to save in one location (Starbase) and save the complete game initialization xml– everything necessary to initialize the state of the game universe.

This worked well, but suffered the following drawbacks:

  • Players complained about only being able to save at Starbase. While the engine could theoretically save anywhere, I was worried about the testing nightmare if they could save willy-nilly.
  • Since a save captured the entire game initialization xml, if I made a change to the master game xml, it wouldn’t be reflected in a save. So I couldn’t easily modify the game once it was released.
  • Probably the biggest problem though was in testing. The game xml evolves as the player plays the game. The only way I could reliably test whether some change to a mission worked was to replay the game from the beginning. This wasted a colossal amount of time as I would make a minor fix, play for twenty minutes only to discover the fix didn’t take because Flex missed the change in XML.

Art & Sound

I’m not an artist but I am somewhat of a perfectionist. When working on Starcom I often found myself unable to continue working on a feature until I was happy with the asset that representing it. I estimated that I spent at least as much time working on various art & sound assets as I did on coding. I lost huge amounts of time working on various ship assets in Photoshop, despite the fact that there are only about a dozen different craft in the game.

If I do a sequel I either need to hire an artist to create the ships, or learn to use a 3D modeling tool to create ships.

The Planets

One visual aspect of the game I really liked were the various planets. While they serve no in-game purpose other than landmarks, they provide a great sense of atmosphere. I think the game would have been a lot duller if every star system looked the same.

I only rendered about a half-dozen unique planets, but created the illusion of many more by modifying the size and colors.

Particle Effects

A lot of the particle effects, particularly the explosions, were pre-rendered in Wondertouch’s ParticleIllusion.  ParticleIllusion creates some very realistic particle effects (particularly of the pyrotechnic variety) for use in film and games.  I rendered them out to bitmaps, then used ImageMagick to stitch them into a “film-strip” bitmap, then scaled them in Photoshop. Once they were imported into the application, they were “blitted” to the particle layer for a high-quality bitmap animation without a lot of CPU expense.

Additionally, sparks were added to the screen to provide some more visual oomph.  These are single pixels drawn to the particle layer.  The pixels were stored in objects that tracked their position, velocity and fade.


One major success of the game was the soundtrack.  It was provided free of charge by Justin Durban.  Originally written for his Kings and Kingdoms project, he graciously allowed me to use of the tracks in the game.  Quite a few players loved the epic atmosphere.

The only problem with the sound track is that as MP3 sound, it’s quite large.  The three tracks combined are larger than the rest of the game put together.  Large file sizes are double-whammy.  Not only do players not want to wait for the download, but there’s a bandwidth cost as well if you host your own game.

To mitigate the download time, I embedded only the first track used.  The other two tracks are loaded later as needed.  This made the game loader faster and reduced the total bandwidth cost, since not everyone who started playing played until the end.


Here’s a problem I imagine most independent game developers have. How do you find unbiased playtesters for your game? Friends and family are great, but they may be reluctant to give negative criticism, or may be outside your target demographic.

Flash Game License has an interesting service where you can buy first impressions. For one dollar you can have an anonymous user play your game and write a review.

The downside of this service is a) you have no idea if the anonymous user chosen is anywhere near your target market and b) they only are required to play for a minimum of 5 minutes.

For a casual game this may be fine, but it doesn’t help you find big problems late in the game.

Once Starcom was released on Kongregate, early players identified several bugs and gameplay problems that were missed:

  • There were some bugs in the save system that led to corrupted save data.
  • There was a bug that prevented the Prometheus mission from registering as complete if a player left the star system before finishing it.
  • The anti-climactic ending was a disappointment for a lot of players.

Distribution & Monetization

To be written…

Initial Reception

Starcom went public on on June 10th, 2009. On its first full day on Kongregate, it was played 68,000 times from 35,000 distinct IP addresses (a play being counted when a user created a new game from the in-game menu or loaded an existing game, so users who visited the page but did not play weren’t counted). After a few early bugs were fixed, the initial reception was excellent with the game ranking 3rd for the week with a score of 4.1 out of 5, the top 1% of Kongregate games.

Jayisgames gave the game a fantastic review shortly after it appeared.

After Starcom dropped off the new releases on Kongregate, the number of gameplays fell off dramatically to about 3000 plays per day.

On June 17th, I uploaded the game to, one of the premier Flash portals on the web. I imagined that starting out of the gate without of any of the bugs from the initial Kongregate release would cause it to be well received and looked forward to shooting to near the top.

I was surprised when it came out of the initial “under review” phase with a score of 3.6 out of 5. Not horrible, but a disappointment. After a few hundred more scores, it had slid further to about 3.5.

Clearly, something about the game bothered a large number of Newgrounds users enough to vote it down. Something that didn’t bother Kongregate users. But it’s the same game, apart from API, there’s no difference. Looking at the written comments on Newgrounds offers no clue– everyone who wrote a comment loved it.

I still have no idea what happened. The demographics between the two sites are a little different, but not that different. My current best guess is that Starcom was sponsored by and features the Kongregate logo prominently. Is it possible that Newgrounds users feel a sense of brand loyalty and voted the game down because of the Kong logo? Or possibly that Kongregate users, upon seeing the Kong logo, decided to vote it up? It seems unlikely, but I have no other explanation.


To be written…

  1. Colin
    June 21st, 2009 at 18:16 | #1

    In my opinion, the time you spent with the graphics and sounds really was worth it. I found the weapons/items, although there were only a few of them, they each were totally unique. In particular, I enjoyed the Havoc Module. That was really epic [creative and original], because it made intercepting missiles a whole lot easier.

  2. Colin
    June 21st, 2009 at 18:18 | #2

    I’ll write about other things later…

  3. June 22nd, 2009 at 03:58 | #3

    Thanks for the very in depth postmortem. Was particularly interested in how you got on with MXML (noticed the UI components when I played your alpha release) as we’re building with flex too.

  4. June 22nd, 2009 at 08:00 | #4

    Excellent write-up. I’m just starting my first game and posts like this are invaluable.

    First and foremost, great job! I really enjoyed playing. Your decision to spend an ample amount of time on art and sound really paid off.

    Being a application developer by trade, I love how quickly I can throw together a business app together using MXML and other goodies found inside the ‘mx’ package. However, when working on my game I find I’m much better off sticking with a pure ‘flash’ setup. I don’t like the weight added by Flex components and as you mentioned it has a strange way of dealing with state updates. I know they’re working on improving this with Gumbo but even when that’s released I’ll most likely stay away. Good for apps, bad for games. Also, given how events seem to fire or update their listeners only when they have free cycles has led me to replace critical event-based game logic with function pointers.

    Once again, great work! I look forward to reading more about your work.

  5. Zachary
    June 27th, 2009 at 00:50 | #5

    All I can say is, great game!

    I too fell in love with the BSG series and wanted a game that mimicked it. When I saw your game on Kongregate I thought it would be like all the other space games- lame. But I gave it a shot and I’m so very glad I did.

    I instantly told all my friends how awesome it was. The adventure of finding new aliens, weapons, and artifacts was just amazing for me. Everything seems very well put together.

    I even asked one of my nerdy friends where I can find other games like this. He referred me to a few older games that I’m definitely going to check out. (Sadly the space adventure market is a bit underrated)

    I’m even more ecstatic you have played Starflight. I owned Starflight and Starflight 2 as a child and I loved them both to death. I felt you followed in that game’s direction for sure, and if you got any closer I’d be willing to pay a small fee to play the game. Of course I believe that would be out of the scope of a Flash project.

    Seriously. Good job. If I had the time to get away from my Internet marketing company, I would for sure be doing what you are. There is no one else doing it, and I think you need to expand and conquer the market.

    Good luck. Keep it up.

  6. June 28th, 2009 at 15:55 | #6

    I played through the game in one sitting and I loved it. I am a regular visitor of Kongregate. I faithful read the Jayisgames reviews. There is a lot of things I could say here about what the game is or what I think it could be but I’d like to address your confusion over the disparity of impressions between Kongregate and Newgrounds.

    Kongregate is entirely a game portal. It allows games to be uploaded by novices with little experience and also highlights the gems that can come from a well known studio or some pixie stick hyped up mountain dew guzzling kid who had a random wonderful epiphany that comes out brilliantly.
    People who play games at any frequency there are going to experience unpolished, uninteresting, or just badly done games. When something “right” or “good” comes around you’ll get a positive response . It’s part of the culture. It’s a hive of developers sharpening the edges of their skills. Honing the goodness and banishing the unnecessary evils.

    In comparison Newgrounds is an entertainment portal. It is not exclusively a game portal. People playing are expecting something “good” and on top of that they want to be entertained. The site also has adult themes which are popular with the demographics there. There is adult humor. This has to be considered a factor in the users expectation. Just briefly looking through their top rated game selection you see a consistent theme +constant fast paced action, +busy graphics.

    Your game is well paced but it’s not concentrated adrenaline rushing “I see red” madness. It’s ok. I like it the way it is.
    There definitely needs to be some more balance to the games upgrades but that is a really minor point.

    The game is fun. You should seriously consider a weekly stage addition. I want to play more but I don’t want to repeat stages. I think Starcom would be perfect for episodic release and you would develop a good player base for when you release new games.

    I would also like to see a multiplayer version. The hyper jump would make team dog fights a very fun experience. There are some serious innovation possibilities on the multi player front. When I was a kid I played a version of space wars on my pc. If you haven’t ever played it you might find it interesting.!

    I would also like to address the base saving. I really feel like it ties you down to the game and invests the player into the actions they take. I didn’t every blow up… I came close and it got my heart racing but after coming out of a seriously hot battle and wiping all the enemies out the games story says you should run from with an inch of health left is priceless. I’m not against more save points but I think it might work for the games dynamics to make them few.

    After playing your game I went looking to play a multplayer game that has been on the net for a while, ARC. It is out of commission but CodeMallet has created a faithful clone version of the game. I suggest you give it a play.

  7. Thomas
    June 29th, 2009 at 22:34 | #7

    Hey there man, I just want to say that I LOVED this game. Like seriously, absolutely LOVED it. It made me wish that there was a console game pretty much the same but just longer. The only things I can say about it is that it would REALLY benefit the game to have some kind of mapping system, or to be able to apend notes onto the jumpgates letting us know where they go. The only other thing, is of course, I wish it where longer and there more to do. :) Awesome work, please make a follow up or a part 2! :)

  8. Andrew Suffield
    June 29th, 2009 at 23:18 | #8

    Kongregate users invariably overrate games. Happens all the time. They are, for the most part, not very bright. Game rating there all follow the same basic pattern:

    1: does not load
    2: lame
    3: sort of half-arsed thing that people make as their first game, having just downloaded flash
    4: actual game
    5: nothing has ever received a score of 5, highest rated game on the site is a 4.5

    And from those categories, it’s +/- 0.5 based on how much people like it. I cannot explain why ratings work out this way, only observe that they do.

    Hence, you can interpret 4.1 as “this is a game, and it’s reasonably good”. Newgrounds has a far greater range of scores (newgrounds users don’t chew up half the values on unplayable junk) so for them, “reasonably good” is around a 3.

    I can’t remember the last time jayisgames did not give a game a fantastic review. It’s a useful links site, but when their every opinion is “wow this rocks buy buy buy and use our referral link” then it doesn’t tell you very much (except that they make a lot of money from referral links).

  9. MichaelB
    June 30th, 2009 at 10:30 | #9

    The game is to “smart” to be rated any higher on Kongregate and Newgrounds. They want easy, or something simple-minded like Sonny. Strategy and simulation rarely do well.

  10. July 1st, 2009 at 02:01 | #10

    I’m a Kongregate gamer. I prefer it over newgrounds for a number of reasons. So whilst I wish I couldn’t agree with what Andrew just said, it’s very much the truth. I’ve seen some absolutely horrible peices on the site continually rated 3-3.5

    Newgrounds scoring system is a scaling system based on user contributions – the more ‘influential’ a person is, the more their rating is worth. from what little I remember of the NG rating system. 1 ‘highly influencial user’ rating 1/5 will take about 40 newbies rating 5 to counter-act.

    I personally think rather than running on ratings initially – you should run on impressions. With the achievement system in place, it’s easy to look at old games with similar ‘ratings’ on kongregate and see how many times they’ve been played, and how many people got to certain landmarks in your game. Usually a ratio between 4:1 and 5:1 (first acheivement vs last achievement – except if it’s an impossible) is a good sign.

    You’ve got (at time of writing) 34k first achievement – 6.5k last – a little over the 5:1 – so you need to do a little bit of work on keeping your players there.

    For me it seemed like I was getting all 3 tracks of music playing at once during your game – possibly something which is turning users off if it’s happening with regularity. Still, I personally really enjoyed the game.

  11. July 1st, 2009 at 09:42 | #11

    I have a lot of experience using Flex for developing a learning application (my day job), and I wouldn’t have used Flex for making a game. I prefer to use plain Actionscript 3 libraries for this.

    Although it’s nice to lay the interface with the easyness Flex offers, I think it brings an unwelcome overhead in speed and memory. Did you felt that if you went with plain AS3 the game would be faster? (specifically in older machines)

  12. kevin
    July 1st, 2009 at 11:03 | #12

    Zach: Wow, that’s really a great compliment. Thanks a lot!

  13. kevin
    July 1st, 2009 at 11:09 | #13

    Derrek: Thanks, I definitely need to lengthen the game in the sequel. I think it’s good that I left people wanting more, but I forgot to create the “more” to give them.

    Multi-player would be excellent, but it’s a very hard thing to do at all, let alone do right. It’s particularly hard with Flash.

    I do remember playing Spacewar as a kid at the open-house when my dad worked at MIT’s Lincoln Labs. Given the wiki description, I might have been playing it on one of the original PDP-1s!

  14. kevin
    July 1st, 2009 at 11:10 | #14

    Thomas: Yes, a better mapping system was definitely an omission in my rush to get the game out the door. But thanks for the compliments!

  15. kevin
    July 1st, 2009 at 11:12 | #15

    Ciro: I don’t think that Flex had a major impact on performance based on my testing. The big hits there were sound (sound is very processor intensive in Flash) and the smoke effect.

  16. andy
    July 1st, 2009 at 19:26 | #16

    so you are making a sequel right? if so i can’t wait, this was a pretty good game

  17. Vinny
    July 2nd, 2009 at 07:37 | #17

    I played the game through on Kongregate, and was impressed. The game is pretty polished, perhaps not quite as polished as a professional, for-pay offering, but that’s hardly anything to be ashamed of. More importantly it’s fun and fairly immersive. After a few minutes I caught myself giving… orders to… imaginary bridge crew with; random-pauses. between. my words; just like William… Shatner.

    But perhaps that’s just me.

    I have only a few requests for the sequel:

    1) Could the heading and maximum effective range of the turret be indicated on the radar? I knew for sure that it reached out past the 250 pixels I could see, but I was never quite sure how much beyond that the rounds were going, nor exactly where they were pointed. Making BVR gunnery easier would make the game easier as well, so perhaps a the gunfire could have a small amount of random dispersion to keep picking off distant enemies from being too easy. Alternatively, the player ship could have multiple turrets the fire to converge on the cursor. Because the guns would not all be firing at the same angle, and getting them to focus on a far distant object would be impossible, you could never hit very distant objects will all of your guns at once, unless they turrets were all colinear. This brings up other fun possibilities; like turning broadside and bringing the cursor in close for a high dispersion arc of fire against fighter targets, and turning parallel for long range bombardment (I’m imagining a long ship with turrets arranged along its axis like a battleship. Hmm, a space battleship, perhaps by the name of Yamato?)

    2) Could the missile target selection please be reworked? I can’t tell you how many times I was targeting one of the modules on the last level, which naturally required flying through their horrifically potent defensive fire, only to have my precious lock on lost because my cursor accidentally hovered over a fighter. Just assigning a key to cycle through available targets, and indicating which one is targeted on the radar would make the missiles far more usable.

    3) This would probably require a major rework of the code, but could you make the view such that the player’s ship is fixed, always pointing up, and the rest of the world rotates around it? If you’ve ever tried to operate an R/C car or aircraft, you know the difference that having the vehicle you’re controlling be a stable frame of reference makes. I feel that such a change would make the piloting far more intuitive, and allow more latitude in different control and vehicle physics schemes. Additionally, you could center the view on some point in front of the player’s ship, so they have a greater field of view forwards and less so backwards.

    4) Retrothrusters. They can make a ship that can instantaneously jump across a star system, warp across great distances through singularities, and they couldn’t put brakes or thrust reversers on it?

    5) Multiple enemy death animations would be fun, particularly on the big capital ships. Having them shed parts as they near destruction would also be a handy visual cue.

  18. Benton Anderson
    July 3rd, 2009 at 21:48 | #18

    The reason why the game received such a low vote on Newgrounds is rather simple. The people on there are very VERY hasty. Most of the people who actually clicked on the game just went there to give a vote, or to just rate it down because of the somewhat long load time. Don’t be offended by any low scores you get on there; even the greatest submissions get bad ratings. Instead, look toward the comments section for a more true rating of the game. Or you can just stick to Kongregate, I find it to be the best site for submitting flash.

  19. kevin
    July 5th, 2009 at 20:55 | #19

    Replies to specific comments:
    1.) Not a bad idea.
    2.) Yes, I’m considering major changes to the targeting system for an eventual sequel. Not sure about the details yet, but different weapons/play styles would use different schemes.
    3.) Google “Return of the Squid” for a game that uses player-centric coordinate system. I personally find that control scheme nauseating, so would have trouble doing development in it :)
    4.) There are retro thrusters (back), but they aren’t instant.
    5.) Another good idea, but animations quickly increase the file size, which is a problem for Flash games that need to stay under 5MB with sound.

  20. kevin
    July 5th, 2009 at 20:57 | #20

    I fully hope to do a sequel, but I’m taking a break from Starcom to avoid burnout. Once I start work on it again, I’ll try to track own people who have expressed interest to beta test.

  21. July 6th, 2009 at 16:40 | #21

    Thanks for the write up! Its an incredibly valuable read.

  22. July 6th, 2009 at 21:08 | #22

    I’m interested in the distribution and monetization. Are you still planning to update the postmortem with that information?

    Or we could chat about it in private and compare notes.


  23. Cy83r K0rp53
    July 9th, 2009 at 19:12 | #23

    Best starship adventure I’ve seen in a long time. I enjoyed the combat and found the controls to be adequate; the only time I’d have trouble was over-steering several times during the more frantic maneuvers against the heavier enemy ships.

    I think the sensor screen should get more love though, it served excellently as a navigation aid and early warning system (what’s that cluster of red blips ahe- OH GOD, MEGA STATION!). Someone said above that range and orientation for the turret would be useful, I agree, mesh it with the sensor display, maybe as a smaller semi-transparent disk within that awesomely teal sensor ring.

    I like the idea of multiple hull types and turret batteries very much, everyone likes more guns and bigger explosions.

    Can’t wait till you start on number 2.

    Much luck and thanks,
    73h K0rp53

  24. Dan00sama
    July 10th, 2009 at 22:48 | #24

    I really enjoyed the postmortem. It really clarified the process of flash game development. Lookin’ forward to seeing the rest of it. Keep the good work.

  25. July 11th, 2009 at 20:04 | #25

    thanks for this!

  26. Mister A.
    July 13th, 2009 at 16:09 | #26

    You should consider creating a WikiPedia article on your amazing game, and perhaps include the postmortem in it. I was telling a coworker about Starcom, but web filters wouldn’t let me show it. A wikipedia article could help your exposure.

    Just a tip; Anyone who begins a comment by claiming a massively-used site uses a rating system which is NEVER reflective of the content’s actual quality, and then proceeds to call the majority of said site’s (HUNDREDS OF THOUSANDS OF..) users idiots, should probably be immediately discredited and ignored.

    In short, Blow me, Andrew. Kongregate has smart folks and fools, just like every other site. No need to bash.

  27. bug_found
    July 14th, 2009 at 06:23 | #27

    using debian and flash 10
    there is a BIG bug: if i press the mouse button the ship wont shoot
    i cant even destroy the training drone at the begining
    but the reactor looses energy as if the cannon sucks it out

  28. Tracy Stoddard
    July 15th, 2009 at 20:17 | #28

    Hey how do you turn in a mission? When I finish the first mission a banner comes up saying that i’ve finished the mission, but there is no pay out and no instructions on how to turn it in

  29. July 16th, 2009 at 02:09 | #29

    Bug report:
    You are allowed to sell the Turbo Turret but it does not re-appear in the starbase Purchase list. In short, if you sell it, you’re screwed. What’s up with that?

  30. Chris Rose
    July 17th, 2009 at 15:37 | #30

    Loved it, was won of the best new games i’ve played. i saw it a work one day and had to go home and play it through. I’m already looking for the sequel.

  31. July 24th, 2009 at 19:10 | #31

    Played it, loved it!

    2 pretty long gameplay-related comments on Kong, so I’ll stick to what you said here ;)

    I’m actually downloading the demo of particleIllusion as I type this – The effects looked awesome in your game :)

    An illusion of speed might be to use the zoom-out feature which some games tend to do (Faster you go, it zooms out to show more)

    Also, when the entire enemy fleet is closing in on you, possible a few more “random encounters” in portals near your base (Bigger, tougher – Some coin reward)

    This will give the player more of the “being over-run” sense, as well as allowing you to make a stronger boss ;p (I liked this boss – Was interesting)

    Oh, and you know when it’s like “Quick in and out for their secret weapon” ?

    I looked at my 15k Armour, and killed everything :p

    Kongregate VS Newgrounds:

    The newgrounds group more prefer instant gratification (Guns blazing within the first 5 seconds of the game) whilst the Kongregate group (Primarily due to the achievements system) are more likely to look at the game as a whole.

    Impressive game, and I look forward to a sequel!

    (Would have liked better shields though… ;p)

    – Reelix

    P.S: This game reminded me of Freelancer for some reason :p

  32. July 24th, 2009 at 19:25 | #32

    - Edit –

    Someone else had my annoying buying error, with “slightly” better description.

    “I came across this bug when i was buying armor. i got a message saying “could not remove blahblahblah” and the armor was gone, the best way to get it back is to load your game save.”

    I had that with Lvl 3 shields, and something else – Seems like a general bug. (Rather annoying to)

    Slight bug:

    If your shield has 4 recharge, it can go above max if the number before is over (max – 3) but less than max.

    198/200 (+4)


  33. Player
    October 9th, 2009 at 15:45 | #33

    An annoying bug I found was the turret suddenly stopped firing completely.
    It happened when I turned the sound off. Now it won´t fire regardless, even if I start a new game.

  34. Francesco
    December 29th, 2009 at 06:27 | #34

    I found a bug, after one of the first missions about recovering a missilelauncher, I returned to base to sell some stuff, but I’m not allowed to exit! When I press “leave starbase” the screen blinks and I’m still inside :(

  35. February 26th, 2010 at 17:07 | #35

    Loved the game, its the third time I’m playing it…
    you could and should continue developing it… I hate the fact that I get to the last boss without buy lots of stuff because I can’t afford it (when without the Armor V this time) and the game ends at the boss… you can create a classic on this one with more playtime.
    Thanks for your effots to do a great game.

  36. Thomas
    March 21st, 2010 at 20:20 | #36

    Yeah. It was a pretty sweet game. Clear you put a lot of thought into it.

    With the whole, length thing, that’s the good thing about non linear gaming. Make it so that people can grind, fight random battles. Maybe have a warp module, which can jump you to different sorts of missions (protect, kill x, collect x) which at different stages of the game have new real missions, made by you, and otherwise, have generic random starmap missions.

  37. PAUL
    June 16th, 2010 at 00:38 | #37

    havoc is also good for mine fields and some small ships
    shield is a life saver some times but a burden from long recharge to use

  38. skyboy
    August 21st, 2010 at 11:06 | #38

    One problem that I consider pretty big (since it makes targeting things difficult while moving) is that while you’re moving, if you fire you bullet will be traveling along with you, and it really shouldn’t do that, since you have to be moving pretty fast to fire a bullet at a right angle to how you’re moving and have it move with you.

    Also I decompiled it to see why there was so much lag on my computer, and even delayed responses to key presses, and key releases. There are a lot of untyped variables (untyped variables or variables typed as * (same thing) are easily 4x slower than a typed object, and for things like int it’s more than 10x as slow), and unnecessary copying of variables all over the place.
    In the sequel, you should explicitly type every variable you create, and you don’t need to make a copy of the XML before you write it to the ByteArray (ByteArray makes a copy of the memory at that location, so when you do that, you have three copies in memory, this can lead to a memory leak).

  39. FlashExe
    August 27th, 2010 at 16:19 | #39

    Just another Kongregate player who wanted to comment and present a couple of ideas on two things that Vinny said.

    1) With the retro thrusters, they should either be excluded from the game, or be activated after the player has stopped moving for a couple of seconds. Otherwise making the ship remain completely stationary would be a real pain.

    2) With the missle lock, an easy solution would be to add a toggle “permanent lock” key. The player could lock on to say, a Destroyer and then press “L”, and no matter what the player moves his mouse over, it would remain locked on to the Destroyer. Then he could either press “L” again, or kill the destroyer to reset the game to automatic targeting.

    Anyways, great game and keep up the good work.

  40. Tino
    September 12th, 2010 at 04:29 | #40

    I am just a player who was delighted by the game.. and i am still hoping that the “to be continued” at the end of the game has a meaning!

  41. Nathaniel
    October 3rd, 2010 at 19:39 | #41

    I thought you might be interested to know that I did a speedrun of Starcom in 7 minutes, 46 seconds. You can find it here:

    I recommend downloading the high quality version (click on the time near the top to go to the download page).

  42. March 25th, 2011 at 10:54 | #42

    Thanks for covering most of the development & marketing cycles, it was really interesting to read!

  43. ambar
    May 30th, 2012 at 03:21 | #43

    Thanks for making such an awesome game; I voted 5/5 for Starcom on Kongregate, NG and JIG. Had tons of fun, and can’t wait for a sequel/expansion pack. Btw, you did notice that the NG rating is now 4+ right? That’s not bad at all by NG standards.

  44. Jens B
    June 16th, 2012 at 11:13 | #44

    kevin :
    I fully hope to do a sequel, but I’m taking a break from Starcom to avoid burnout. Once I start work on it again, I’ll try to track own people who have expressed interest to beta test.

    I’m still looking for Starcom 2. ;)
    I don’t need much changes; I’d suggest having a larger universe; and having for instance 3 ways of solving the game; eg. 8 things you have to do, then 1 out of 3 that you can choose yourself, to vary the game.
    I stilll play Starcom, even though I’ve completed it a bunch of times.
    It’s a great game for relaxing (but as I wrote above, it would be awesome with some variations, in case you play it more than a few times).
    The look and feel of the game is excelent. Controlling the ship is excellent.
    Unfortunately, Flash has a problem, so when in my browser, I click another application, and then return to the browser, the keys don’t work anymore, and I have to start over.
    I’m happy that there is a way to save the game. ;)

  45. Azriphael
    October 31st, 2012 at 00:36 | #45

    In my play-though, I bumped into a nexus before picking up the missile launcher item. As a result, it de-spawned and I was never able to collect it. I went through the whole game using only my ship’s cannon. A future game should be careful that any “unique” items don’t simply vanish from the universe if the player leaves a zone. This would alleviate a huge frustration, where I repeatedly trolled back through the zone I was supposed to collect the missile launcher, hoping it would drop.

  46. FlashExe
    December 9th, 2012 at 13:51 | #46

    Hey. I’m assuming that you have kind of gotten out of developing games and all that and, I just wanted to thank you for making two of the best flash games I have ever played. Sadly I can only speak for myself, but if you’re still making games or you’re getting back into programming them, you still have fans that support your work.

  1. June 18th, 2009 at 14:12 | #1