Talk:Boulder Dash (video game)

Amstrad CPC version released as early as 1984?
I just don't think that early a release date for the CPC can be correct, as the CPC 464 wasn't launched until April 1984. Thus, the CPC platform was in its early infancy at the time BD was originally published (for the C64 etc.). I therefore took the chance of editing that part of the article. --Wernher 09:00, 31 August 2005 (UTC)


 * Either there was a failure in Matrix, I dreamed it, or I really played Boulder Dash on my Amstrad CPC 464 (tape) back in the early 80's. I'd swear that the last option is the correct one :) More information, including a screen capture of the main menu (where you can clearly see "First Star (c) 1984") and the scan of the tape's cover --Devotee 18:15, 31 August 2005


 * I'm not so sure that the "(c) 1984" statement actually means that the game was released for the CPC in that year---I think the 1984 date is there to indicate the year of original publication. Looking at the cover scan, notice that it says "Copyrighted 1983, 1987", which might mean that the port was released during that latter year. But, I could still be wrong. Do you have any 'corraborating' info to confirm your memory?


 * Now, if we could only dig up a scan of a magazine review with a date on it, we'd be closer... --Wernher 14:02, 2 September 2005 (UTC)


 * Update: issue #1 of AA (Oct. '85) has a review of BD for the CPC. That's something, clearly. --Wernher 14:25, 2 September 2005 (UTC)

Cellular automaton
The following paragraph was removed:
 * It may be interesting to note that most of the rules for game object movements in Boulder Dash can be implemented efficiently using a cellular automaton. For example, there are four different cells representing butterflies moving in different directions. On each game iteration, if the space ahead or to the right from their path is empty (space cell), the butterfly cell is moved there; otherwise, the cell is not moved, but its direction is changed to next one in counterclockwise order. The spreading of amoeba cells use the help of a pseudo-random number generator which determines the chance of infecting neighboring cells, and there is also an extra counter for the total number of amoeba cells occupied. Also, falling rock has different characteristics than stationary rock, and the transition between these two states takes one iteration. The original implementation on 8-bit computers even used in-place modification in sequential left-to-right, to-top-bottom order to save memory. Extra cell types were used to make sure that cells to the right or bottom would not be updated again.

Now, I'm aware of the Wikipedia-concepts but I think this paragraph is much more a self-evident statement than a proposition - many descriptions of the game logic (and in fact the game itself as far as i know) use the cellular automaton concept, even if they don't call it that. I vote for putting the paragraph back, maybe with a dispute-tag over it. // Gargaj 11:35, 1 March 2006 (UTC)


 * As the person who removed, I'll say... you *might* be right. Personally, I was erring on the side of caution. It might be worth waiting a day or two, seeing what everyone else thinks and then (if it's clear that's what people want) put it back without a tag. Fourohfour 14:26, 1 March 2006 (UTC)


 * To me it reads like a technical description, and as such I'm not particularly fond of it. It makes sense to me but only because I both know cellular automaton well and once tried coding Boulderdash in QBASIC from scratch (Rogue-style, of course) and failed miserably. It's also slightly ambiguous ("If the space ahead or to the right... is empty, the cell is moved there") but that can be fixed. Nifboy 14:51, 1 March 2006 (UTC)


 * As the person who wrote the original chapter, the result was perhaps too technical. Maybe it would be sufficient to claim that the game rules are remarkable easy to express in form of a cellular automaton. Are examples of rules of encyclopedic value? I do not know. Please feel free to reword. But I readily admit that the description of 8-bit implementation is original research that required disassembling the original game code. Sorry no userid.


 * Hmm. While I agree that it's related to cellular automaton, it's an entirely different application thereof, and that's what counts. Compared to the games of the time, Boulder Dash could calculate and change the state of a much larger playing field with many more dynamic objects by dividing space and time into larger "chunks". Essentially, framerate and precision were cut down to make room for much larger, dynamic levels. Nifboy 18:58, 1 March 2006 (UTC)


 * A (very belated) note from someone who has coded both cellular automata and a Boulder Dash clone: I think it is wrong to describe games of this type as cellular automata (or 'implemented as' cellular automata). There are, I think, several reasons for this.  But perhaps the most obvious is that all the cells in games of this type are not updated 'simultaneously'.  If you look at the rules for Conway's Game of Life, or Wolfram's 1D cellular automata, or Tron/Critters automata - and I think nearly all others - one thing they have in common is that the state of a given cell at time T is *entirely* determined by the state of cells from time T-1.  Conversely, it is very difficult to write Boulder Dash style games in this way.  Consider roaming 'bad guys' from one of these games.  Suppose two moving bad guys are approaching each other head on and about to both move into the same empty cell.  Usually, in the implemention of a game, one will just 'win': the one that gets updated first, probably because the game is updating the grid bottom-to-top, left-to-right (or some such).  This is one reason that these games can usually update the game state (grid) 'in place'.  Whereas cellular automata usually have to maintain two 'grids' (or, equivalently, sets of active points): each update only reads one grid and only writes into the other (which mimics simultaneous updating).  Then the two grids can be swapped, with the update process then going the other way (then just repeat).  Games like this usually have a different set of rules being applied to a given cell depending on its current 'type' (e.g. rock, diamond, exit, etc).  Cellular automata usually have a single, global rule for all cells.  Games like this also have 'action at a distance'.  For example opening the exit when a last diamond (or enough diamonds) have been collected.  This is a non-local change, unlike changes in cellular automata, which are usually local.  However, it is true that very simple games of this type - say with just a handful of 'objects' in the game - are automata-like in some respects, having cells and rules for the cells, and usually updating the 'state' of a cell in the grid, rather than 'moving' (i.e. changing the co-ordinates of) 'objects' - unlike, say, Space Invader style games.109.146.150.169 (talk) 16:26, 22 August 2016 (UTC)

Fireflies and butterflies
Fireflies and butterflies don't explode directly on contact with Rockford. They explode only if they are trying to bump into Rockford, or vice versa. If Rockford only brushes against a firely or a butterfly when both are moving in parallel, but opposite directions, Rockford is safe. Unfortunately this does not happen as often as the bumping. J I P | Talk 12:39, 12 October 2006 (UTC)

No, they don't have to bump into Rockford in order to explode. The fact, that there are cases where Rockford can walk parallel to them or opposite, which in fact is not always possible but only on certain conditions, is related to the scanning algorithm. The behavior is completely forseeable, and in fact, experienced gamers know, how to do this. Also keep in mind that only the 8 bit versions as well as the CGA MS-DOS version has the original game physics. Many later ports behave quite differently to the extend that 1:1 coverted caves often don't behave like the author's intention. LogicDeLuxe 21:34, 27 July 2007 (UTC)

I thought that Fireflies and butterflies have the same movement algorithm, but it's not clear from the description.
 * They are similar, but one big difference is that they have opposite pathways.LogicDeLuxe (talk) 20:17, 1 January 2008 (UTC)

Here's how it really works. Objects in the cave are scanned from upper left to lower right. They are moved immediately after they are scanned. If, BEFORE moving, a firefly or butterfly is adjacent to Rockford, it explodes. Since entities do not move at the same time, Rockford is allowed to be next to a Firefly after he moves, and if he is scanned before the firefly is next frame, he can escape death with a move. If the firefly is scanned first, Rockford dies. — Preceding unsigned comment added by 74.211.60.216 (talk) 01:38, 25 August 2018 (UTC)

Rockford "home conversion"
Are we certain that the Rockford coin-op actually came before the home computer versions? Considering the fact that all of Arcadia's other arcade titles are essentially existing Amiga games modified for the Arcadia hardware (essentially an Amiga 500 modified into a coin-op), I'm skeptical that this is the case, but hesitant to change without firm release dates. Both Amiga and arcade versions are dated 1988, as far as I'm aware. Seeing as how the home ports were billed as "Rockford: The Arcade Game", I'm wondering if this wasn't a case of a simultaneous home/arcade release for the sake of cross-promotion. Moby Games does list the DOS version as being released in 1987 (as opposed to 1988 for all of the other releases, including Amiga), but I'd take that with a grain of salt. Gnu 03:01, 24 April 2007 (UTC)

Dubious external link
Boulder Dash for Windows by ZX Games -> http://www.zxgames.com/en/boulderdash.shtml

I'm not exactly sure, but I think this link/site has a somewhat commercial motive. Should it be removed? Whats your opinion about the website? DaSjieb 20:15, 30 May 2007 (UTC)


 * I removed the link for now, due to the commercial motive I explained above. DaSjieb 16:14, 5 June 2007 (UTC)

The site seems to be claimed that their games are licensed. If this is true, then it's legit, but they coudl just be lying through their teeth. Contacting First Star Software is probably in order. 74.211.58.183 (talk) 11:13, 14 January 2013 (UTC)

CFR
Removed cfdnotice, cfd has completed. --Kbdank71 17:02, 9 May 2008 (UTC)

Renamed to Category:Rocks-and-diamonds games. —Frungi 00:49, 24 June 2007 (UTC)

DoomDash
Does somebody know, which Hungarian magazine it was released in? And which issue? —Preceding unsigned comment added by 80.98.119.245 (talk) 23:17, 25 January 2008 (UTC)

Etymology
Might the title be a play on balderdash? Is this obvious to an English speaker? (If so, I'll mention it in the French page, since it's not obvious to us French.) Palpalpalpal (talk) 12:13, 2 January 2011 (UTC)

Yes, it was intended as a play on balderdash, and yes, it's obvious to english speakers. It's in the Peter Liepa interview. 74.211.58.183 (talk) 11:11, 14 January 2013 (UTC)

Atari original cover (First Star version)
Why's the awful NES cover shown on the main page and not the Atari original? I think that should be changed. — Preceding unsigned comment added by 87.144.39.100 (talk) 10:17, 30 June 2014 (UTC)


 * Couldn't agree more, and 7 years later I did just that. Griggorio2 (talk) 21:25, 6 March 2021 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified one external link on Boulder Dash. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20130616095534/http://www.ysrnry.co.uk/articles/boulderdash-22.htm to http://www.ysrnry.co.uk/articles/boulderdash-22.htm

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 17:23, 11 January 2018 (UTC)

Problems with this article
The section about the objects in the game has now been deleted twice with the reason "Wikipedia is not a game guide". Then the article was tagged about not having a "gameplay" section. This seems to be contradictory - you can't remove material and ask it to be added at the same time. I have written a short basic gameplay section that doesn't list all the objects in detail.

Also, in the current state, over half of the article's length is a list of various versions of the game that were released. It takes up more of the content than the rest of the article put together. J I P &#124; Talk 16:32, 24 January 2021 (UTC)