Posted on March 14, 2009
Mines and Bricks in 64K?
Mines and Bricks in 64K?
for the first and second jury prizes in the 4K game competition is over. Two simply incredible entries won
Dungeon Romp). Unfortunately neither my Mine-X 4K (Mochi
Comp version) or Steve’s Neon Bricks 4K (Mochi
4K Comp version) was good enough to warrant a judge prize. Also, after
looking at the competition for the audience prize, I would not even vote for my
The competition is fierce among the other (non-winners) for the audience prize and I am especially impressed by this
3D entry –
Pillars as well as this pretty much full version of
(one of my favorite games of all time). Every game was very well done, and
quite an accomplishment in 4K, but I would like to also shout out the entries by
Scott Delamater as other personal favorites.
Many people will probably call us “major tools” for creating Mochi versions
of the 4K games (to each his own dentifrice) , but we really did it to see what
the difference is in size for adding in those features. Since I use Flash
Develop/Flex framework in AS3 and Steve uses Flash CS3 and AS2 it gave us a nice
idea of the differences between the two and what we can expect for games we want
to make in the future under our own size constraints. (If you want to see
us a two undeniably major tools, check out the first 8bitrocket video podcast
that will be up shortly).
Steve’s Neon Bricks will make a very nice Arkanoid clone once is able
to work out some of the collision detection and power up limitations he was
forced to put in place because of the 4k limit. His current plan is to create a
more advanced Silverlight version first, and then go pack and create the 64K
For me, my next step is to attempt to make a real game out of Mine-X 4K. The judges did a good job of picking apart its weaknesses:
1. The player ship’s velocity is not added to the player shot velocitybr />
2. The levels don’t progress very well.
33. Pretty much a clone of Asteroids and Geometry Wars with nothing extra
(except the AWESOME radar map =))
I plan to make a new version that runs in the limited file size, but still
add in game play, visual polish and some sound enhancements. I also need to put
in a goal for the player to complete on each level that is NOT simply “kill all of the enemy”. That will still be one of the tasks, but I think I will add in a collection element. I might make the player collect a series of stationary mines that connect to the rear of the player ship and act like a sort of whip that can be used to destroy the flying mines. Also, I might add in a galaxy map that the player can use to fly to the sector he/she would like to conquer. There will be 5 different sectors with different colors and enemy. Once all 5 have been cleared, the player moves to a new galaxy with 5 more difficult sectors. I also might add in a shield and more powerful
shots for the player to collect.
On the code front, I hope to add back in the optimized game timer, object
farms and a few of he classes that I had in the original 8K version of Mine-X
before I stripped it down to 4K.
I need to fit all of this in, along with new enemy graphics and sounds, but want to keep it inside a very limited file size. Obviously, it will be larger than 4K (especially with Mochi boards and ads), but I am not quite sure how large. Steve and I are trying to come up with an 8bitrocket mini game standard size, but if you saw
Steve’s last post, once he added in the Mochi elements and our standard retro game cartridge title screen, he was at just under 100K. He is using CS3 and AS2 though. I added those
elements to Mine-X 4K and came out to just under 40K. That would give me 24K for sounds/graphics and game play enhancements, which COUL:D be enough, but probably won’t be. The big reason is that
I use Flash Develop and the Flex framework exclusively. Sounds cannot be embedded in any format other than MP3 in this configuration. I will need at least 10-20K for some basic retro sounds, leaving me with no more than 5K for game play
and graphics. I could set my goal to 100K and see what comes out, but that is
still under debate as the 64K branding is more in line with out 8-bit moniker
If we do choose the 64K limit, I assume we will start calling our new small
retro games under a brand like “8bitrocket 64K Micro Retro” and stick with it
for a while. We are both interested in developing under constraints that will
allow us to let go of projects and get them into the wild quicker than we have
in the past. I personally would like to get a 64K game done every two weeks, but
that is probably a little aggressive. We will probably develop with the idea
that the game size before Mochi, but including the title screen will need to fit
in under 64K. Then, once we add leader boards, encryption, and ads it can go
beyond that. If 64K is too limiting, we might stretch to 100K (or 128K) but I
feel 64K (since it is the a very recognizable 80’s memory constraint) will be
the right limit. Then again, we might just have whole set of limits
16/28/32/64/128 and just try to make the best game we can in what ever file size
it fits into. I don’t see us branding anything over 128K as a “micro retro game”