Shadow of the Beast III (Action Platform) (LHA) (Amiga)

1992 · action · Amiga · The Data Archivist V0.01

MANUAL (EU) : https://archive.org/details/shadow-of-the-beast-iii-1992/mode/2up VIDEO LONGPLAY : https://archive.org/details/Amiga_500_Longplay_039_Shadow_of_the_Beast_III MUSIC (O.S.T) : https://archive.org/details/07-full-of-water Source : https://en.wikipedia.org/wiki/Shadow_of_the_Beast_III Shadow of the Beast III is a platform game developed by Reflections and published by Psygnosis in 1992 , exclusively for the Amiga . It is the sequel to Shadow of the Beast and Shadow of the Beast II . Plot and gameplay In this game, Aarbron has regained his human shape but must defeat Maletoth once and for all to become fully human. Shadow of the Beast III has four distinct stages instead of one big area. The game places less of an emphasis on the action elements so prominent in the first two games, instead preferring a more cerebral approach. Development Shadow of the Beast III began development in October 1990, and was developed in two years. [2] The graphics for Shadow of the Beast III were developed by Martin Edmondson on an Amiga A3000 using DPaint IV . [2] Beast III was coded on a 25Mhz PC running PDS 2. [2] The One interviewed Mark Jones, Shadow of the Beast III's graphic artist, for information regarding its development in a pre-release interview. [2] Edmondson notes that the original selling point of Shadow of the Beast was its graphics, stating that "Apart from how many colours and layers of parallax and monsters we could squeeze on screen, no thought went into it whatsoever", and expresses that Beast III will 'retain the characteristic look and feel of the original' alongside significant changes. [2] Edmondson states that " Beast I was a graphics showcase and some people found Beast II too difficult ... In Beast III our aims are to keep it looking good, retain the puzzles of Beast II and make it easier. It's going to be much more accessible." [2] The non-linear game structure eased graphic design, and Edmondson expresses that "For me it's [much easier] to start off drawing a forest than to gradually create a forest environment you can walk into." [2] Edmondson and Beast III's programmer Paul Howarth outline their ideals of a 'good action game', stating that "The most important thing is the feel. If the game is very bulky to control, things stick when they hit walls and the collision detection is a bit naff, it's very annoying to play, no matter how addictive the gameplay might be. The whole thing should run very smoothly and be easy to pick up and move around.", and furthermore emphasises the importance of overall appearance, saying that "You can have an excellent game but if it looks really, really bad it's not going to sell because you've got a problem with screenshots. They're not going to attract anybody so no-one's going to buy the game." [2] In Beast III's development, graphics were prioritized, with Edmondson stating that planning began with "we say what we want the background to look like - whether we need a hazy skyscape, mountains [etc.] ... then we concentrate on the lighting effect." [2] Background objects were drawn as free-hand drawings, and then digitized . [2] After planning graphics, the game speed, scrolling, how the main character functions, and the controls are discussed. [2] Edmondson expresses that after this planning, "Then we try and wind a game around these ideas if we can." Edmondson states that "We must be the only people left who don't use SNASM - we just find it too slow" and expresses that he personally considers specially designed editors and utilities 'a waste of time.' [2] Edmondson goes on to state that "a lot of people write very complicated map designers and editors, but I can't see the point in justifying spending three months writing something like that ... We use the most basic tools we possibly can, so we just get stuck into the game and work exclusively on that." [2] None of the data from the first two games is reused, and Edmondson explains that "It's probably slower to mess around with original code than to write it again. On top of that there's the problem that the original code for Beast I was so bad. It was the first thing we really did seriously and when you look back on it, it's very slow and inefficient and could have been done 10 times better. We always like to start from scratch." [2] One of the most difficult aspects of Beast III's development was parallax scrolling ; Edmondson compares Beast I and II's methods of scrolling, saying that "In Beast I , we chose the most obvious and the easiest way of doing it, but the problem with that was that you couldn't have monsters running over the foreground at the same time. They had to be very spaced out and nowhere near interesting parts of the map ... [For Beast II ] we fixed it so that we could have monsters around ladders and bits of buildings, but the background suffered and basically just a silhouette." [2] The parallax scrolling technique developed for Beast III allows monsters to be in points of interest w