I entered
Samar mainly to look for someone who could write the music for the game :)
- but not straight away, because I had to quickly start to code for a music collection for them (Catollica).

Luckily, it was also at the time that the young Owen (CRD) joined Samar;
and therefore the mission of creating music for the game was given to him.
He did it so fast; that the title Bomberman C64 was released for the competition organized at the beginning of 2007, the competition was called "Game Over (view) Freestyle Jam", where it gained second place, and meet
with a warm welcome from players, which encouraged me to finish project.

I received an offer from the publisher; however I felt that the project
still didn't look quite right, especially as I had cut out the multiplayer mode. Years passed; and the project was developed sporadically. Its true
I took long breaks on the projeect, often pushing it into the background;
with respect to other matters (e.g the "Dream Travel" demo or "Jagged
Sword" game preview). The project was still in the back of my mind. In
2010 Owen sent me a new great soundtrack for the game that was definitely closer to Bomberman, and this pushed me back into action. At the end of
2012, we had already coded something like the final design view - and a
preview was released. There was still a lot of interest from publishers, However we both decided to give it a commercial release on cartridge -
mainly because it is a very durable medium.

It's hard to determine how long the game actually took to code! but it certainly wasn't 10 years. :) Before the release of the Bomberland
Preview, we again refreshed the whole code. A lot of refinements meant the game now wouldn't fit on the ROM cartridge. I think there aren't many
games that use the rom card the way we did, such as depacking data all the time. Most of them work by transferring the packed game at the beginning
and unpack it into the computer RAM and that's all. In our case,
transferring data and depacking was done 'on the fly' happening many times within the game, turning the ROM cartridge into extended memory. Through
this project I learned a great deal about programming, and has really
improved my skills. Work on the game also provided me with many challenges
and I learned to overcome them, giving me a great deal of pleasure and satisfaction.

- - - - - - - - - -

Q: Why did you think we needed another bomber clone, and what are your thoughts on Protovision's "Bombmania"?

AC: Bombmania by Protovision has proven to be a very successful party
game, especially with their very own joystick adaptor that they developed specifically for these kind of games. However; in my humble opinion, it
isn't a true conversion of the original arcade Bomberman by Hudson Soft.
In terms of graphics, music and playability. Despite the differences in storyline and extra features, we wanted to release a conversion that
played, displayed and sounded like the arcade version, as well as other
clones; like Dynablaster (Amiga/PC).

AS: As Conrad said really, Bombmania as well as existing clones on the
C64; are far from what we offer in this version and what
Dynablaster/Bomberman on other platforms offer. The main difference is the
way you control the player. In Bombmania, the movement is more like
Boulder Dash. That is discreet, so after determining the direction by joystick, for a while we passively watched as the hero moves
unconditionally to the next field. Yes, some love Boluder Dash and
probably a control model also fits them. For me, BolderDash works, but in bomberman games this gives you a lot of limitations.

So I tried to create a player control that was closer to DynaBlaster, with movements in any time-dependent motion of your hand. For convenience,
there is also the added possibility of sliding on the corners of obstacles
- thereby giving you the ability to move even more quickly. I needed to
add that and this is one of the elements in Bomberland, which I'm really
proud of. A graphic character is just a matter of taste. :)

- - - - - - - - - -

Q: You use the top border for the scoring and level information. Did you think about opening out the borders completely for the game; thus giving
you more game area?

AC: In terms of vertical borders, it is technically impossible to display
high resolution graphics within 40 columns "outside" the main screen.
First of all, this would require sprites... without any professional
coding tricks, you can only display 8 sprites in one row. Each unexpanded sprite uses up 24x21 pixels, which gives us the total of 192 horizontal
pixels for 8 sprites. This is not enough to cover
high-resolution/multicolour graphics for the whole border. Expanded; all 8 sprites (i.e. doubling the horizontal scale) can cover all 320 pixels, but this means that 2-colour graphics per 2 pixels can only be achieved for the most high-resolution display. In the late 80s however, a well-respected
coder named Crossbow achieved a text screen with 3 rows of 40 hi-res
characters in both the top and bottom borders. He did this using, what I
like to call, the "$3FFF trick"; he cleverly drew characters in the sprite data. But this would not be suitable for a game such as Bomberland. In my opinion; vertically opening the borders are perfect for informal graphics;
such as scoreboards or scrollers, which has worked well in many games and
demos from the past 25 years. Skull, of course; has found nice ways of
making the scoreboards beautiful in terms of multicoloured hi-res graphics
and sprite overlaying in the right positions. :)

AS: I am not going to talking about the technical details of the C64 like Conrad has, but I would like to add that this actually is not possible
while trying to maintain the quality of a game. Also as Conrad said; there
is the problem of the number of sprites on a single horizontal line, this
can only be only 8. Despite many tricks, no method of obtaining a larger number of sprites is possible to use sensibly. But the main problem is, opening the side borders would take time away from the processor. Doing
this for the entire length of the screen (like the FLI, NUFLI etc.) would completely impact on game performance - 2/3 of the CPU time would be
"wasted" (in ntsc even more). In our game the side borders are open at the screen introduction/history part, and displays of a new password. The
effect of the border scroll is shown in the main menu.

- - - - - - - - - -

Q: On some of the levels the playfield actually scrolls around with the
player (in single player mode for example). What prompted this and why
didn't you just stay with a static playfield?

AC: Official Bomberland/Dynablaster clones published by Hudson featured scrolling levels, so we wanted to achieve this for our version of the game
as well. The magic of VSP (Variable Screen Positioning), discovered by JCB/MeanTeam in 1987, helped us achieve this. :)

AS: Conrad is right, but I would also like to add that on the C64, there
just aren't enough games that use smooth scrolling on a full "normal"
screen 40x25 (320x200 px), mainly because it takes a lot of CPU time and usually some part of the screen. A few lines at the top or bottom are allocated to information about scores, lives etc. Lets take SEUCK games as
an example... they use the entire volume of the screen, but are often slow (mainly through the use of multiplexer sprites) as there is a lot more
action on the screen. In Bomberland, the horizontial scroll was quite
simple to obtain (it's a VSP effect - unfortunately, not every c64 handles
this correctly), the vertical scrolling really affects the machines performance. There is just a small part of the code responsible for doing
the smooth scrolling and without shakes or judders, even under NTSC.

- - - - - - - - - -

Q: How important was the multiplayer option and, although you stopped at 5 players, could theoretically mo

--- MBSE BBS v1.0.01 (GNU/Linux-i386)
* Origin: Dragon's Lair ---:- bbs.vk3heg.net -:--- (39:901/280)