Solar Fortress Chronicles: Hours 10 – 13
Solar Fortress Chronicles: Hours 10 - 13
Note - I am rapid prototyping a retro game in my spare time and keeping a diary of what I do each hour of the project.
This another update on my latest mini retro remake, Solar
Fortress (pronounced Star Castle).
I got off to a slow start in hour 10 by somehow "fat fingering" my for-loop in such a novice manner that I spent an extra 30 minutes trying to discover my stupid error. Needless to say, you can come up with some very "Interesting" results if you substitute the counter in your for statement with the variable holding the pre-calculated length of your array:
(for var ctr:int=arraylength;arraylength >=0;arraylength );
The 2nd and 3rd arraylength references should be ctr. When I looped though my projectiles for update, only the last one shot would update and when it's max life was exhausted, the next would move, then the next, etc. It looked cool, but really worked like ass (obviously).
My next task, after player ship projectile movement, was to test their collisions with the outer ring of the "fortress" (pronounced castle). My first idea was so simply test a circle v. circle between projectile and the the outer ring circle. That worked well at first, so I continued with a loop through the red line segments on the outer ring only if the circle v. circle was true. The outer ring segments are rotated BitmapData inside bitmaps and because of this I needed to use a standard hitTestPoint between the center of the projectile and the ring segment. I would have used BitmapData.hitTest but because the Bitmap instances do the rotation, not a matrix on the Bitmapdata, the collision would not have been valid.
This seemed to work properly until I the player shot out 10 of the red line segments. At that point, the dynamic collision circle on the outer ring went haywire and began expanding and contracting at will. Although this effect was actually pretty awesome (I'll bank it for the later Zarjaz phase), it didn't make collision detection work at all. I quickly replaced the dynamic circle radius calculation with a fix radius and it started to work properly.
I then added hitpoints to the ring segments, which necessitated my created a class for the segments to hold current and max hitpoints. Up to this point I had not treated the line segments as a separate class, but was using a simple Bitmap instance. In rapid prototyping games like these I have a set of questions that I ask myself before I create a class for an object. I usually have to answer yes to two of these before I create a class for an object:
1. Do I need more than one of these?
2. Do I need only one of these, but is it so specific that it would consume too much game loop (or other parent) code to manage it "in-line" and be better encapsulated as a singleton?
3. Does it exceed what a standard Flash built in class can handle - needs its own attributes, or must encapsulate other objects for ease of management?
Originally, the line segments answered 1. Yes. 2. No, 3. No., so I didn't give them a separate class that extended Bitmap, I just used a Bitmap instance for each. Now that I needed hit points for each segment (because they don't die at the first hit), I re-wrote all of my code to use a RingSegment class that encapsulated all of the attributes and specific functions for the RingSegments.
When the player destroys a certain number of segments in a ring, the ring grows back (this increases per level to make the game more difficult). I had been treating the 3 ring segments in my Fortress class as a set of individual attributes made up of:
1. An array of segment Bitmaps (now RingSegment objects).
2. I sprite (ringsprite) to place the rings on
3. A holder sprite to rotate the ringsprite - the ringsprite was placed at -1/2 width, -1/2 height s it would rotate properly when the holder is rotated.
I had three sets of these named with ring1_, ring2, and ring3_ prefixes, but it was now time to buckle down and decide if I needed to create a class for the actual rings:
1. Do I need more than one of these? YES
2. Do I need only one of these, but is it so specific that it would consume too much game loop code to manage it "in-line" and be better encapsulated as a singleton? NO
3. Does it exceed what a standard Flash built in class can handle - needs its own attributes, or must encapsulate other objects for ease of management? YES
It was now time to spend a couple hours fixing this up and creating the new classes. After I was complete with my new classes, I ran it, fixed the 150 errors and warnings I had created for myself, and now had a little more progress to show in my spare time retro game.
(below is the current build - arrows to move, space to fire).
Tutorial: Using Bit Wise Operations To Create A Repeatable Sequence Of Multiple Level Designs In Code
When creating my game for the Urban Squall 4K Competition a couple months back, I decided to go back and try to remake an old game that was written in ActionScript 1, and bring it into the modern era. Since Breakout is one of my favorite games of all time, I decided to take my old Brickbasher game and see if I could redo it in 4K. I recalled that the the original prototype for Brickbasher was about 8K, and I also knew I had better programming chops now than back in 2002, so I was fairly confident that it could be done.
After stripping out all the useless code, and re-writing a more efficient game engine, the core was about 3K. This was cool, but it left me with one problem: How do I create interesting levels to play? While the original Atari Breakout had just one level design, modern "Breakout" style game have dozens of intricate levels to destroy. Brickbasher used a "one byte per brick" design that simply would not allow enough levels to make it interesting in 4K. To make this work, I would have to dig back to some advice I received from one of the star Atari VCS programmers, David Crane.
Back in 2001, David Crane came to my place of work to pitch a game idea for an RFP we were conducting. After the meeting, I caught him in the hallway, and professed my undying appreciation for his work. Since he did not instantly run way, I asked him something that always bewildered me: how did he get so many screens into the game Pitfall! The Atari VCS could only address 4K of memory (more with RAM bank-switching), but Pitfall! (and River Raid, a game he helped design) had 256 different screens. This always seemed impossible to achieve within those limitations. He told me that to create the Pitfall! world on a VCS cartridge, he used a combination of a polynomial sequence, and bit wise operations. In short, he took a set of 256 randomly generated numbers (mind you, only randomly generated the first time ), and then checked specific bits in each number to know what to draw on the screen (pits, scorpions, treasure, etc.). When that was done, he found the perfect place in the sequence to start the player, and the Pitfall! world was born.
I had never done anything like this before, but this seemed like a good way to try to create multiple levels for a 4K breakout style game.
My first idea was to create completely random brick placements based on a sequence of seeded (repeatable) random numbers. However, when I tried this the levels looked predictably lame: like a set of completely random bricks, and this is not what I wanted at all.
Instead, I came-up with another concept, also loosely based on the Atari VCS. When programming the VCS, developers had a "background" screen available to them. However, this "background" only took-up 1/2 the screen. The logic for this was based on what the Atari VCS was originally designed to do: play 2-player Pong and Tank! games.. Each of those games has an play field that is essentially identical at both ends. If the play field was going to be identical, the VCS hardware designers did not have to waste extra power trying to create a full background, when they could just copy 1/2 the background, mirror it, and have the same effect. This is why many Atari VCS games have symmetrical play fields.
Armed with both these ideas, I tested what a play field would look like using a set of blocks, copied 3 times (upper left:normal, lower left:flipped, upper right:mirrored, lower right:mirrored, flipped). When I did these copies, what originally looked like a set of random bricks, became a symmetrical play field.
(First set of randomly generated bricks)
(Copied, and flipped second set of bricks)
(Copied and mirrored 3rd set of bricks)
(Copied, mirrored, and flipped 4th set of bricks)
Now I had a concept for how I would build levels out of random (but repeatable) placed bricks, but I still needed a way to generate those levels. Going with David Crane's idea, I needed a repeatable set of numbers. After playing around with this for a long time, I settled on the level number (1,2,3,...). Yes, this was not really a random sequence, but it very well could have been. Since I did not have the bytes to spare in 4K to hold a list of numbers or complex random seeding function, this would have to do.
Next I needed to test the bits of levels number to see if I should place a brick. Each set of bricks was 6x6 (copied 4 times to make a 12x12 grid of possible bricks). My decision was to AND the level number with the product of of the row and column of the brick I was placing. If the value was was "1" (on, true,yes), I would place a brick in that position:
[cc lang="javascript" width="550"] if (l & j*i)
[/cc]
If the brick was supposed to be placed, I would place put it in all 4 places (upper left, lower left, upper right, lower right) the screen, achieving my symmetry:
[cc lang="javascript" width="550"]
makeBrick((j) * 50,(i * 18) +20, level,i);
makeBrick((j) * 50,182 - (i * 18), level,i);
makeBrick(600-(j+1) * 50,(i * 18) +20, level,i);
makeBrick(600-(j+1) * 50,182 - (i * 18), level,i);
[/cc]
Here is the full code I used to test for the bricks and place them on the screen:
[cc lang="javascript" width="550"]var l = level;
while (bricks.length <= 0) {
for (i = 0; i < 6; i++) {
for ( j = 0; j < 6; j++) {
if (l & j*i) {
makeBrick((j) * 50,(i * 18) +20, level,i);
makeBrick((j) * 50,182 - (i * 18), level,i);
makeBrick(600-(j+1) * 50,(i * 18) +20, level,i);
makeBrick(600-(j+1) * 50,182 - (i * 18), level,i);
}
}
}
l++;
}
[/cc]
Using this method, I was able to create 20 distinct screens. By further adding difficulty by making bricks that had to be hit multiple times (differernt colors), the number of possible levels increased almost two-fold. If I had decided to increase the grid size from 6x6 to anything larger, the possible symmetrical designs would have increased as well. I plan to remake this game in the future with more bricks, and even more interestingly random, symmetrical levels.
Since Neon Bricks 4K is quite a difficult game, I have taken screen shots of the first 20 levels, so you can see the product of the bit wise operation, number sequence, and screen copy ideas all in one place:
(Level 1)
(Level 2)
(Level 3)
(Level 4)
(Level 5)
(Level 6)
(Level 7)
(Level 2)
(Level 
(Level 9)
(Level 10)
(Level 11)
(Level 12)
(Level 13)
(Level 14)
(Level 15)
(Level 16)
(Level 17)
(Level 18)
(Level 19)
(Level 20)
And that is it. A very simple use of some old ideas, to create a richer game than would have been possible otherwise.
Solar Fortress Chronicles 2: Hours 5 – 9
Solar Fortress Chronicles 2: Hours 5 - 9
This is a short update on my latest mini retro remake, Solar
Fortress (pronounced Star Castle).
I wasted a lot of time today working on collision detection for
Solar Fortress today. I think I finally have a decent path toward
my final set of code, but I spent an inordinate amount of time mostly
frustrated.
My goal was to use BitmapData collision detection between
the player ship and each rotating line segment in the fortress walls.
For some reason when my objects were rotated inside Sprites, the
collision detection would not work. It seemed that the rotation was not taken into account in the collision map. Hmm, I think I remember this from the
docs I read a long time ago, but for the first three hours today I
thought I could do detection on rotated Bitmaps (and the associated
BitmapData) inside my sprites. This seemed to work on and off with
strange results most of the time.
It worked perfectly for 2
identically sized objects and I was actually able to cobble together
a few sets of different sized objects and associated offsets that
worked OK, but it was not reliable enough to go forward with (yet, I
may go back to this for the missile to wall hits).
Finally, I decide to add 4 hit points to the ship and tested this
against a rotated (but enlarged) yellow line segment. This worked
pretty well, so I started to code up a loop to test all 4 ship hit
points against all circle segments when I had a revelation...In Star
Castle, the player ship never actually goes inside of the 'Castle',
so why waste cycles checking 4 hit points on the ship against every
line segment? Why not just do a circle v. circle between the ship and
the fortress. So, that's what I did. It took a couple of tries
because I was late and I forgot that RADIUS is not DIAMETER (duhh, maybe I should have spend more time in Math listening instead of drawing space ships) and
needed to make a few minor adjustments before it started to work
pretty well.
One thing I have not done (other than some rudimentary code) is
figure out the correct collision reaction between the ship and the
fortress. This and the ability to shoot the walls is next on my list.
Here is an interactive (arrow keys) swf of the current hour 9 build.
I left in the test objects and the player ship 4 hit spots as they
might prove useful down the line.
Solar Fortress Chronicles: Hours 1 – 4
Solar Fortress Chronicles: Hours 1 - 4
I am in the midst of creating a game of ever expanding scope
called Blaster
Mines. It started out as a relatively simple extension of Mine-X
4K. The initial idea was to make a game similar to Bosconian
and get it done quickly in my spare time. After being absolutely
floored by the quality of Dave
Munsie's RetroShoot, I have decided to spend more time crafting
Blaster Mines into what will eventually be Retro
Blaster 2. This will be a lot of work, so in the mean time I am
doing experiments with smaller games to see what might work well in s
360 degree scrolling blaster. That's where Solar Fortress comes in.
It is my attempt to re-make a retro classic (Star
Castle) in as little time as possible, but still retain a
modicum of quality and try to modernize the original in at least one
way. What I learn from this game I will add to Blaster Mines in some
capacity.
Star
Castle (Flash Version)
So, it's obvious that a Flash version of this game already exists,
so I am not being highly original by creating my own version, but I
hope to differentiate mine to some degree. In any case, the purpose of this
exercise is to investigate, learn, and also to fill out the
8bitrocket
catalog with more retro titles.
I don't steal graphics, so I have to use my limited skills and
experience (drawing space ships in Math books in 4th
grade) to craft up something that I hope people will find enjoyable
to play, and at least pleasant to look at. Having said that, I don't
plan on any of these mini-retro classic updates to take more tan
20-30 hours to complete so I can't linger on the visuals too long.
My first 4 hours on Solar Fortress were spent instigating a little
into Star Castle, the game I plan to re-make. Star Castle was one of
the first games I was addicted to as a kid. In the early 80's, there
was a Star Castle machine near our home in a Safeway
grocery (where a Coffee Bean and Tea Leaf sits now in Manhattan
Beach California). Steve, Eric Barth and I would play that game for
hours (or with as many quarters as we could beg out of our parents).
I think I probably played the game 100 times before I was able to
destroy the castle the first time. The shriek of joy that from the
three little boys behind that strange video game must have scared
most of the Reagan era frugal shoppers. I think I remember parents
hiding the eyes of their children as they walked by the three little
video game obsessed weirdos.
My investigation started by taking a screen capture of a Flash
version of Star Castle. I measured the size of the fist 45 degree
line in the outer ring and it fit a 32x32 tile (how convenient). I
actually was not planning to use tiles for this game, but I because I
eventually will use BitmapData collision detection, I needed to start
on familiar ground. I then fired up Flash Develop and began a fresh
new empty Main class. I created a shape and drew a red line 4 pixels
wide from the bottom corner (0,32) to the top corner (32,0). I drew
that into my 32x32 BitmapData, added it to a Bitmap. Then I began
playing with the angles of rotation to see how the lines in the
castle wall actually fit together. It turns out that each of the 12
lines is rotated 30 degrees more than the one to its left. I whipped
up some code to loop though and rotate 12 lines for the outer ring. I
then added those to a Sprite (and to an array for easy looping). I
moved that sprite to -1/2 width x, -1/2 height y and then added it to
a holder Sprite. The holder is rotated clock-wise on each frame tick
to provide the Star Castle ' like wall rotation. I had always
wondered how this was done. I think it must have been much more
difficult with the Cinematronics
hardware in the 80's, but AS3 makes it pretty easy.
For the inner yellow and green wall rings, I repeated the same
procedure but made each segments 24x24 in the yellow wall and 16x16
in the green wall. My first test of running the code had me stuck in
nostalgia right away.
The final of these 4 hours was spent plotting the player ship in a
32x32 png and then translating that plot to a code based vector line
drawing. This took much longer than I thought it would, but I am
satisfied with the results (so far).
(My
ship magnified 2x). It looks similar to the Star Castle ship, but not
exact. The remaining game characters (plus new ones I put in) not
resemble to original as much as this one does (at least I hope). I
wish I had some of my 4th grade Math texts to use as a
reference.
Here is a non-interactive swf of the current hour 4 build.
A Toy Never Played With Is Not A Toy At All : …palindromes…
Above is one of my favorite songs by one of my favorites 80's/90's bands, Drivin N Cryin is named "A Toy Never Played With Is Not a Toy At All". I found myself humming this song to myself a couple days ago, and I had no idea why I was doing it. Even though Drivin N Cryin were once of my favorite bands, I probably have not listened to them in 5 years. However, old songs and their appropriate lyrics have a way of popping up from my subconscious just when I need them, and think that is just what happened.
You see, I had my new game ...palindromes... up on FlashGameLicense for 2 weeks, and while it got nice comments, it got no bids. Over the 13 days it was up on the site, I retooled the game with several new features suggested by the good people over at FlashGameLicense, but still, no takers. I was not sure what the reaction would be to the game, since it is essentially an "unscramble the word" contest made in the style of "word mini game" on the Nintendo DS. It has no flashy title screen, and very minimal graphics. I think it plays very well, but you actually have to PLAY it to find that out.
Anyway, after the game toiled for those two weeks, my subconscious got the best of me. Sure, it would be nice to make loads of money from a license, but that is not the only reason I make games. I make games to be PLAYED. If they sit on a virtual shelf gathering dust, they do me no good at all. The monetary rewards (what little they are right now) are nice, but the psychological rewards can be just as...well, rewarding. I've always felt that bringing a little joy to someone's day, however small, was worth the effort of making a game.
And I believe that is why that flowed to my brain this week.
"A Toy Never Played Is Not A Toy At All!"
If my game simply sat waiting for some fantasy "big money" guy to come along with a huge check, it would never get played. And if it never got played, was it really worth the time I spent making it? It *is* a game after all. It's also not my best game, or something that I was pinning my all hopes and dreams upon, it was just a fun little diversion I wanted to try to see if I could make work as game. And there is was again. A game. A Toy. A Toy Never Played With Is Not A Toy At All.
"A Game Never Played Is Not A Game At All"
So I took ..palindromes... off of FlashGameLicense.com, and released it into the wild (Kongregate, Mochi, FlashGameDistribution, MindJolt). You know what? I felt good.
I felt a great sense of relief and satisfaction yesterday as I watched the game filter through the viral Flash Game Portals (i.e. FreeWorldGroup.com), saw that Mochi made it a "featured game" for publishers, and watched the game-plays wrack-up close to 5000 for one day (a record for me). No, ...palindromes... will not conquer the world, but people are playing it, and that is almost as good.
Now I can move on to the next one...
Game Programming Tutorials: What Would You Like To See?
Hey all you 8bit Rocketeers out there!
Jeff and I have been culling through our email and web traffic info over the past few days in a quest to figure out what type of content to fill this site with.
What we discoverd was this:
People love tutorials.
So, that is the plan. Along with new games, we plan to write shorter tutorials that focus on or more aspects of game development/game design in Flash/Flex/Silverlight.
So, here is a question for you:
What would you like to see?
Are there any retro-remakes you'd like to see a tutorial for?
Are there any game styles you would would like to see explored?
Now, we probably won't be giving full source for games, but we will give enough so that any experienced and/or serious developer could use the code to make some cool stuff.
So, again, tell us what you'd like to see. I'm not saying we will do it, but we are open for suggestions
…palindromes… goes live
This game was created as a test to see if this type of straight-ahead word game could become popular on the web. The jury is still out...
Interview with Retro Shoot Creator, Dave Munsie
Interview with Retro Shoot Creator, Dave Munsie
Dave was nice enough to take time from his busy schedule to answer a few questions concerning his latest Flash masterpiece, RetroShoot, and to wax nostalgic on his Atari ST roots.
8Bitrocket:
You were pretty prolific as an Atari ST Magazine disk game developer, what was your favorite game that you developed?
Dave Munsie:
I coded several pd games and a few utilities before ST Review asked to me to write some games for their cover disk. As far as my favorite game for ST Review, it's hard to say. They were all coded very quickly using a game engine/shell I had developed. I don't think I spent longer than a couple of weeks on any of those games. I liked my version of Deluxe Invaders (not ST Invaders) and Bugs. Berzerk was a lot of fun to code, as well as my Donkey Kong clone.
Dave Munsie's Kid Kong (image from www.atari.st)
8Bitrocket:
I played both Deluxe Invaders and the Donkey Kong Clone A LOT! Do you still play any of them via emulation or on a 1040ST (etc)?
Dave Munsie:
I still have my Mega ST but I haven't really played with it that much since I left the ST scene. A few years back I was hoping to have time to work on my ChopLifter Clone for the ST but, alas...things didn't pan out. I never played with ST emulation until about 2 years ago when I received an email from a fan who fell in love with my Square Off game, and I booted it up on an emulator and agreed, that's a fun game!
8Bitrocket:
I would love to try the Choplifter clone. Did you make any commercial, packaged ST software?
Dave Munsie:
The closest I came was a series of enhanced pd/shareware games I did. Asteroidia, Frantick, Squareoff. I decided to spend a little more time on these, try to polish them up a little bit and put them out there as shareware. I think I ended up selling around 12 total licenses. During that time I was also going through some *cough* bullshit *cough* issues with an unnamed company which affected my ability to market those games. Needless to say there's a few pissed off customers who never got their registration codes. Not too long after that, I declared all of my ST efforts public domain and placed full versions on the internet.
Dave Munsie's Evader (image from www.atari.st)
8Bitrocket:
Did you play other people's games on the ST? What was your favorite game?
Dave Munsie:
You know..this is horrible to say. But I didn't play a lot of ST games! But when I did it was always something from the Bitmap Brothers or Psygnosis. Xenon 1&2 were (and still are) brilliant. 
8Bitrocket:
Well, you are American, (like Steve and I) and there just we're not many good ST games stateside. We had to go to import shops to find good games (other than Phantasie I,II,II and Dungeon Master that is). Did you develop for any other systems other than the ST in the 80's / 90's?
Dave Munsie:
I did some early stuff on the Atari 8bits. I coded a drum machine on the Atari 8bit that has digitized images of myself hitting the drums. It was marketed by a small (1 employee) company called "ReeveSoft". Hiliarious if you ever get a chance to see it. 
8Bitrocket:
Steve and I were Atari 800 fans as well. I would love to see that Drum Machine program! Back to the 16 bitters, when the ST scene died in about 1992/93 did you move on to make games for any other platform?
Dave Munsie:
Nothing really worth mentioning. A friend of mine introduced me to the concept of making money with computer software on some weird platform called "PC". We started up a software company, created a bunch of utilities, screen savers, etc, and made a shite load of money before the internet burst. Actually it was amazing, I coded a zip utility in 3 hours time and over the course of it's lifetime I'd say it made close to 300k. It was an amazing time to say the least. Oh how I long for those days. lol..
I didn't do any game coding again until around 2005 when I started using VB6 to write a high level game engine called the "DXGame Engine". I wrote a couple of small projects which I released as shareware, released 1 decent game called "RetroBlast" then took a break from game coding when the VB market kind of fell apart when the .NET thing appeared.
RetroBlast
I started game coding again in mid 2007 when I fell in love with BlitzMax. I ported all of my engine code to that language. Coded a complete high level game engine that included sprites, particles, emitters, tile map, explosions, gui, etc, etc, called it "MGE" for Munsie Game Engine. I've only coded 1 game with that engine, but it comes out this Holiday Season (2009). The game is called Christmas Clix. It's also going to be ported as a WiiWare game and hopefully onto the XBox, Mac, Iphone as well. I'll be doing a Flash version as well.
Christmas Clix
8Bitrocket:
I created a few free-ware DOS games in that era, but I never did try to sell them...maybe I should have! Speaking retro games, When did you get into Flash game development?
Dave Munsie:
February of this year. (2009) One of my resolutions for 2009 was to learn a new programming language. I also wanted to eventually write games that ran in the browser. At some point in the near future the line between os/browser is going to blur, but until that happens I realized the most sensible thing to do was take a look at flash. I first downloaded the free trial of CS3, and I wasn't too excited about the whole timeline thing, working with the Flash IDE, etc, etc. Actually I was going to forget it and put it off till later until I came upon FlashDevelop and AS3. Now THERE was something that made sense to me! Give me a text editor, a way to embed resources and I'm good to go.
8Bitrocket:
Ahh, Flash Develop, you couldn't have chosen a nicer way to go! It is my favorite too! You got going pretty quickly if you just started in February, is Retro Shoot your first completed Flash game?
Dave Munsie:
My first flash game was "Fun2Pop" followed by "HeartsABreakin". Two very, very simple games that were nothing more than experiments to see how I could move things around the screen. RetroShoot started off as a very basic "Mouse Avoider" game. Not once did I write a game design document or plan anything. I literally just coded that game on the fly. Obviously that shows in the game, but I tend to think that's what also gives it it's charm.
8Bitrocket:
How is AS3 development different than ST game development?
Dave Munsie:
Well...if you throw out the Flash fluff then they're actually fairly similar. You have your main loop, you draw your background, you draw your sprites on top of the background, etc. Of course there's a lot more to Flash which I hope to exploit as I learn more about it.
8Bitrocket:
Retro Shoot is simply awesome. It is probably the best Flash Retro game that I have ever played. Did you need to use a lot of optimized techniques and tricks to keep the frame rate up?
Dave Munsie:
First off thank you for that amazing comment! I appreciate that very much. I came across this neat tutorial about coding an asteroids clone in AS3 on a site called "8BitRocket.com". lol. At first I was using standard display sprites for everything and I was disappointed to find out they were very slow on less capable hardware.
After checking out that tutorial I started playing around with copypixels and realized the best way to get any performance out of flash is to go old school. I spent a couple of weeks writing a custom sprite engine that allows me to have the best of both worlds, pre-rendered sprites using copypixels or dynamic scaling, alpha, etc, sprites using draw. I totally bypass using display object sprites for anything in game. For title screens, or GUI elements sure, but in game it's strictly bitmapdata, copypixels and draw. I also use a custom delta timing system which allows me to process logic/render once per loop.
I tried using a timer / update after event system (fixed logic) but it only worked well on modern hardware. On older systems the frame rate was so unstable I almost lost hope in Flash until I ported over my delta timing from my earlier engines.
My dev/test system is an older 2.9ghz Celeron with on board Intel graphics. Just last week I finally (after 4 years) upgraded the memory from 512mb to 2gig. My development environment was really chugging on just 512mb, but now everything flies again so it's like having a brand new box! lol. I tend to stay old school with my programming so I don't get spoiled and start whizzing around 1000's of sprites and have it only work on my son's suped up game rig.
8Bitrocket:
Wow, I'm happy that my tutorial was helpful in your early studies. I like doing things the 'old-skool' way when I can too. Speaking of Old Skool, the music in Retro Shoot is very Wally Beben like (he was a prolific ST?Amiga/C64 game music creator). Did you do it yourself?
Dave Munsie:
No I did not. But it is the kind of music I would have composed if I had time to do it. The talented Matt McFarland did that. His website is: http://www.mattmcfarland.com/.
8Bitrocket:
On the note of "doing it yourself", did you create all of the graphics and effects for Retro Shoot by your self, or did you employ an artist?
Dave Munsie:
A few years back when I coded Retroblast in VB6 I did most of the graphics but also had a few images designed for me. I ended up not using some of those images and decided to plug them into RetroShoot. Otherwise some of the backgrounds are licensed media as well.
8Bitrocket:
What's next for Dave Munsie? Are you going to move on to Physics Based Tower Defense Match 3 games, or do you plan to make more retro titles?
Dave Munsie:
Actually, I think I've been waiting for Flash all of my life. lol. Since I don't have much time to spend on a game, I finally have a platform where I can get ideas out the door quickly and not be too concerned that it doesn't have the latest and greatest fx, media, etc. However, I do realize the flash market is in a transition stage. The games are getting better, the media is getting better, etc, etc. I have several projects in development, a few of them retro, a few more mainstream, etc. However, they will all be simple and hopefully fun. I do hope to work on longer more content driven games in the future. One of the flash games I'm working on is called "GemClix" and I hope to have that done in about 2-3 weeks. 
GemClix
8Bitrocket:
Richard Davey is a hero and friend of mine. When I needed a kick in the ass to change my career in the late 90's, his Little Green Desktop site was the medicine I needed. How did you hook up with him and did you know about his site before he started to help you with API implementation?
Dave Munsie:
I made contact with the awesome Mr. Davey through FlashGameLicense.com. This is embarrassing, but I didn't realize who I was communicating with until at some point the Atari ST was mentioned and we exchanged accomplishments. Needless to say I was honored to have him helping me. What a talent and such a nice guy!
8Bitrocket:
Do you have a Twitter account or Blog/site that people can subscribe to / visit to get updates on your latest games / happenings?
Dave Munsie:
Yes: http://twitter.com/JGOware. As usual, my programming habits are very sporadic. I might code 18 hours a day for a month, then take a few weeks off, do some fishing, jam on my drums for a bit, etc, etc. lol. My main site is http://jgoware.com where I promote some of the products I've coded the past couple of years.
8Bitrocket:
Thanks, Dave. I hope to have you and your games be a real fixture on 8bitrocket as we build into an empire =). -Jeff Fulton
Dave Munsie:
No problem Jeff! Thank you for taking an interest in this smallest of smallies. (Small indie developer.)
Silverarcade Goes Live: A Couple Of Our Games Featured
The guys over at SilverArcade have launched their portal dedicated to games made in Silverlight. They are offering a $.50 eCPM, which is quite good.
Since they have acceptsed a couple of our games, and since I think it is a cool idea, I'd like to see them build some traffic over there. Here they are:
These are certainly not our best games, but they are a starting point for the future of our Silverlight development.