Was in heutigen Programmiersprachen gang und gäbe ist, die Technik Dinge von X nach Y zu kopieren und dort anzupassen, ist in Assembler nicht so einfach möglich. Der Grund: In heutigen Programmiersprachen gibt es keine Sprungmarken mehr, diese müssen aber mühsam angepasst werden Assembler. Es darf ja (ausser bei modernen relativ adressierbaren Assembler) keine zwei gleichlautende Sprungmarken geben. Anders gesagt: Copy&Paste ja, aber zu einem Preis: Generierung von vielen neuen Labels und damit auch jede Menge möglicher Fehler und viel Neu-Testing.
Und dies trifft Videogames besonders, da Videogames geradezu von Bedingungen leben (ifs, loops etc).
Gridrunner (Jeff Minter) – 68000 ATARI ST Assembler:
// {} vs a: b: // Mehr Subroutinen in Assembler > Frage an die Entwickler // Vgl dazu die Demoscene
Es ist eine Sache Software/Games für alte Systeme auf Emulatoren zu entwickeln und eine andere sie dann lauffähig zu machen auf Orginalhardware. Die Unterschiede sind schnell erklärt: Viele Emulationen ’simulieren‘ über Probleme hinüber (Werte sind meist geleert oder null gesetzt, Hardware ist doch leicht anders etc).
Am Besten sieht man das etwa bei sehr spezialisierter Hardware wie der Vectrex (Beispiel VecZ). Beim Simulator gibt es kein Flimmern, keine Hardware am Anschlag, keinen Kathodenstrahl, der kondensiert die gesamte Helligkeit abbildet etc.
Aus diesen Gründen war es interessant zu sehen, ob das Spiel TheHolyCube einfach so läuft auf einem Orginal C64.
Das Spiel kann per FlashCard und einem SD2iEC (Simuliert ein C64-Diskettenlaufwerk – Karte und Stecker zum C64-Laufwerk) relativ leicht als .PRG ‚aufgespielt‘ werden.
Das Resultat: Es läuft – in den ersten Test ohne Probleme. Selbstverständlich ist der Screen ein modernes TFT und dadurch erscheinen die Pixel als Pixel und sind nicht verschwommen wie bei einem Orginal CRT. Dies muss als nächstes getestet werden, um dem ursprünglichen Phänomen und der Wirkung gerecht zu werden..
Nutzung der C64 Architektur für eine GameEngine in Assembler.
Prinzipiell stellt der C64 Bildschirminhalt (wie schon mehrfach beschrieben) im Textmode oder im Grafikmode dar. Es gibt verschiedenste Grafikmodi: 320*200 in 2 Farben oder 160*200 in 16 vordefinierten Farben (Multicolormode). Wobei nur 4 Farben pro 8*8 oder 4*8 Block gesetzt werden können: 3 jeweils wählbare neben der allgemeinen Hintergrundfarbe. Dabei lassen sich diese Modi wie beim inspirierenden System Atari 400 hin und herschalten anhand des Rasters und damit Mischen. Sichtbar in unendlich vielen Spielen und auch Grund für die Teilung des Screens bei ManicMansion.
Das Problem: C64
Betrachtet man die Spiele, die mit dem C64 entstanden sind, ist man einigermassen fasziniert, da wirklich alles aus dieser ursprünglich als Gameconsole konzipierten Maschine rausgeholt wurde. Dabei ist der C64 alles andere als ein Paradies für Entwickler. Angefangen von den Text/Grafikmodis, über die Repräsentation des Bildschirms als RAM in Blöcken. Dann die maximale Auflösung von 320*200, die völlig überdimenstioniert ist für den Prozessor, der nur 8Bit ist (650x). Die Hardware und der Prozessor sind dabei eigentlich nicht aufeinanderabgestimmt und vieles ist einfach möglich günstig gelöst. Als Entwickler* hat man zu keinem Zeitpunkt das Gefühl, dass auch nur einen Moment an die Entwickler* gedacht wurde. So fehlen elementarste Dinge für Gamedevs – etwa (und das haben alle Consolen natürlich eingebaut) die Möglichkeit Text in den Grafikmode zu rendern. Hier soll allen Ernstes mit Modis umgeschaltet werden. Dies führt dann auch zu der immer künstlichen Trennung von Bild und Text in C64 Games. Die Sprites können von 0-386(?) in X und 0-300 (?) gesetzt werden. Dadurch können sehr schön Sprites reinhuschen in den Screen, dafür ist es die „Hölle“, die Sprites zu verwalten, da der Prozessor nur von 0-255 rechnet. Dann muss ein LowerByte hin. Wer dann auch noch eine eigene Kollisionsabfrage will, ja der hat viel „Spass“. Anders gesagt: Der C64 ist ein Bolide mit einem schwachen Herz. Zu erst sieht der Prozessor ja einigermassen schnell aus, bis man die Taktrate und die möglichen Instruktionen runterrechnet auf eine Frame. Dann zeigt sich dann sehr schnell, dass ohne die Zuatz-Hardware für Sprites, Scrolling oder die Zusatzmöglicheiten des SIDs, der C64 recht langsam ist. Es ist dann auch verständlich warum, der Apple II leider nie zum Gamecomputer avanzieren konnte in die Breite. Selbst mit den grosszügigen 64KB RAM stösst man sehr schnell auf Probleme bei der Entwicklung und es wird schnell klar, warum viele Spiel auf dem C64 so sind, wie sie sind..
Man mag Jack Tramiel danken für sein „Computer to the masses and not classes“, aber dass darum die Programmier* dabei Unterklasse werden, das bleibt im Dunkeln und wird auch fast nicht thematisiert, wenn man* so gemütlich ein C64 Spiel spielt.
GameEngine: ‚Philosophie‚ (Designrules)
In der entwickelten GameEngine wurde versucht aus diesem „Ungetüm C64“ etwas zu machen, das keine Herausforderung in der Nutzung ist, sondern den Entwicklern* hilft. Es ist eine TopDown-Entwicklung. Die Engine wurde auch so entwickelt, dass sie für verschiedene Genres genutzt werden kann. Nicht implementiert sollte Scrolling werden, da dies immer eine je eigene Entwicklung benötigt (Playfieldgrösse, vertikale oder horizontale Ausrichtung etc) und schwer abstrahierbar ist.
// ToDo: Vergleiche mit real entwickelten Spielen in jener Zeit und deren Ansatz – je eine eigene Engine für jedes Spiel oder eine Metaengine
Technologie: KickAssembler
Als Sprache wurde KickAssembler benutzt. Dies ist ein scriptbare Assembler in Java mit der Möglichkeit klassische C/Java-Kommentare zu machen // & /* */. Zusätzlich gibt es vordefinierte Scripts. Durch Java als Grundsprache läuft der Assembler auf allen Systemen. Eine Anforderung, die wichtig ist, weil Entwickeln auch auf Mac ein Goal des Projektes ist. Die meisten anderen Tools laufen vor allem auf Windows bzw. sind Plugins im Universum von Microsofts VisualStudio.
Das Compilieren ist (nach Installation von Java und dem Wechseln in den Ordner) simple:
Er funktioniert einfach mit Drag&Drop, lädt sehr schnell, die Joysticks etc sind Standard mässig installiert. Dinge die gerade beim Platzhirsch VICE (https://vice-emu.sourceforge.io) konfiguriert werden muss.
EngineArchitektur
Die Architektur der Engine orientiert sich an frühen Engines (keine Eventengine) und basiert auf einem oder mehreren Loops (die linear angeordnet sind). Hier sind es: Titelbild-Loop, Menuloop, Submenloops und der Gameloop.
In der Organisation und Bewirschaftung der Daten wird auf die Eigenheiten/Verteilung durch die Hardware eingeganen. Das heisst, es gibt nicht nur eine Klasse GameObjekte (wie etwa in Unity), die alles abbildet sondern zwei Teilsysteme:
Diese zwei Objektkategorien sind bei Consolen und auch beim C64 als eigene Hardware/Teilsysteme abgebildet.
Dies führt dann auch zu verschiedenen Interaktionen/Events zusammen.
Auflösung und Playfield
(Viele 8Bit-Consolen nutzen Playfields für den Background bzw. die Umgebung/Architektur vgl. Intellivsion Ausnahmen natürlich Atari 2600 und Vectrex)
Für die entwickelte Engine wurde der Multicolormode genutzt. Damit lässt sich am meisten rausholen aus den Grafikmöglichkeiten (Die meisten Games verwenden auch diesen Mode). Anstelle des vermutlich gedachten Playgrounds mit einem Multicolorzeichensatz verwendet die Engine 8*16 Pixel grosse Blöcke. Das sind pro Block 4 Blöcke des C64 Grafiksystems.
Die Nutzung eines so „Niedrig“ aufgelösten Rasters erlaubt es, dass das Playfield eine Liste von 0-255 Feldern ist und so leicht manipuliert und abgespeichert werden kann.
Die Engine nutzt dabei eine Liste mit den Blöcken (Blocks) und ein aktuelles Playfield. Dieses kann gerendert werden in den Screen. Einzelne Blöcken lassen sich updaten. Es gibt ein System zu Animationen der Blöcke (synchron) für Gameplay wichtige Animation und ein System, das asynchron Animation bietet.
Die Menuszenen wie auch die einzelnen Szenen (alias Levels) sind als Levels im Speicher abgelegt. Dadurch muss nur ein System betreut werden und auch in Menuscenen kann etwa das Animationssystem benutzt werden.
Block & Playfieldtool
Um dies nicht nur im Code nutzen zu können, wurde ein Tool entwickelt in Processing. Dieses Tool ist zum einen ein Designtool für die Blöcke und zum Anderen ein Tool zum Gestalten der Playfielder (Levels).
Das Tool speichert die Daten als „rohe“ JSON Daten bei den Blocks und einzelne Levels. Gleichzeitig werden die Daten per .asm File gespeichert und können dann eingezogen (include) werden.
Das Tool ist so aufgebaut, dass man jeweils nach links Blocks designed und nach rechts die Levels. Im Bereich des Blockdesigns müssen die Farben nicht ausgelesen werden, sondern werden automatisch aus den benutzten selektiert. Dies macht es einfacher zu designen. Eine farblich angeordnete Palette macht das Pixeln einfacher.
// ToDo: Welche Spiele nutzten Leveleditoren und wer arbeitet Hardcore in den Listen/Tables oder nutzte einfach Files? Zumindest für die 16Bit Generation lassen sich Leveleditoren nachweisen (Bsp. WAR HELI) und sind sogar in die Games (KRACKOUT) eingebaut.
Gestaltung von Blocks/Szenen
Das Gestalten von Blocks zur nachfolgenden Mehrfachverwendung ist eine Designsparte für sich. So müssen die Blöcke zwar unique aussehen, dürfen aber auch nicht zu unique aussehen, damit sie nicht zu fest ausfallen. Das Umgekehrte gilt für den Hintergrund, dieser muss Regelmässig aber nicht zu regelmässig aussehen. Die Limitation des C64 pro Tile/Segment nur 4 Farben (Hintergrund nicht wählbar und 3 Vordergrundfarben) machen es sehr schwierig interessante Dinge zu gesalten. Erschwerend kommt die wirklich schwierige (weil einfach seltsame Farben) Farbpalette hinzu. Zu guter letzt ist erst auf dem C64 laufend, dann klar, wie es wirklich aussieht. Da liegen dann die eine oder andere Farbe schon gar eng beieinander.
In die Blocks gehört auch ein Alphabet und Zahlen. So lassen sich Strings mit Zahlen ausgeben in der Grafik. Zusätzlich verfügt die Engine über die Möglichkeite 1/4 Blocks, klassische Tiles/Blöckchen zu zeichnen. Dadurch lassen sich normale Texte in 4×8 Pixeln rendern.
Gestaltung von Levels/Szenen
Levels besitzen wie Blöcke eine spielmechanische wie auch visuelle Funktion. Um Levels zu gesalten gibt es besondere „Commandsblöcke“, diese Spawnen etwa den „Spieler“ oder den Gegner etc. Diese werden dann umgewandelt in normale etwa Hintergrundblöcke.
Die visuellen Designregeln transportieren die Mechanik, dürfen aber auch nicht zu statisch sein und sollten irgendwie leben. Siehe dazu anderen Blogbeitrag.
Einige Beispiele:
Menuscene ohne Menupunkte
Ein Level mit Spielerspwanpunkt und Enemyspawnpunkt
GameObject bzw. Sprites
Das problematischste Element ist die GameObject/Spriteverwaltung. Diese besteht aus einer Liste von GameObjekten, die auch gerade Sprites abbilden.
Ein Objekt hat jeweils die Länge von 17 Bytes:
0
1
2
3
4
5
6
5
6
7
8
9
10
11
12
13
14
15
16
x
xshift
y
yshift
w
h
state
statesub
arg
behaviour
animtodo
animindex
mina
maxa
animtype
animeoden
Positionen
Die Sprites können in zwei Modis genutzt werden. Von 0-255 im Boxmode. Hier endet die Darstellung nach 256 Pixeln oder im 320 Pixel-Mode: Hier rechnet die Engine intern mit 2 Pixeln und dem Offset. 270 Pixel in X Richtung sind: 135 Pixel (x). Möchte man das Sprite auf 271 Pixel bewegen, so gibt es dafür eine ShiftNumber (x-shift). Da der C64 einen Rahmen von 20 px und 50 px hat, muss dies jeweils abgezogen werden für Vergleich oder Kollisionen mit dem Playfield.
320 Pixel-Mode (0-160, 0-250):
Animationssystem
Das Animationssystem ist simpel. Jedes Gameobject hat einen Animationstyp (Endlos,einmal,einmal&destroy). Per MinAnimation und MaxAnimation definiert man die Animation. Und los geht es.
GameObject-GameObject-Collision
Die Engine führt eine Kollision von jedem Objekt mit jedem anderen durch. Kollisionen können in der Schleife abgefragt werden.
Avatar-Playground-Collision
Die Engine prüft per Default Avatar-Playground-Kollisionen und ist damit in der Lage Objekte aufzunehmen. Objekte können dadurch einfach Objekte ‚auflesen‘ aus dem Playfield.
Spritetool
Das SpriteTool arbeitet ähnlich wie das Blockeditor-Tool. Geht aber auf die Eigenheiten von Sprites ein. Das heisst es können zwei Grundfarben ausgewählt werden und dann pro Sprite jeweils eine Zeichenfarbe.
Anwendung
Die GameEngine wurde bis anhin in 3 Projekten angewendet: – Squarez – ein einfaches Spiel, das im Rahmen des CHLudens-Projekts durch die Geschichte der Computer nachprogrammiert wird. – TheHolyCube – eine OneButtonSpiel von la1n ein OneButton JumpAndRun mit Animationen und vielen Levels – ‚Züri brännt‘ – ein einfaches Adventure im Rahmen des CHLudens-Projektes zur Frage der Machbarkeit und Einschränkungen der Hardware/Medium: Game(HardwareC64) (In Entwicklung)
Fazit
Die GameEngine umfasst die meisten genutzten Funktionalitäten in Spielen mit Ausnahme des Scrollings und des Sounds.
Starbyte Super Soccer is one of those early football management games (genre: strategy). The name had to be chosen that way because there were other products with the same name Super Soccer, for example from Nintendo. And Starbyte itself already had another soccer strategy game on offer with Soccer Manager Plus (1989). Two years later, the new soccer manager game focused on the German Bundesliga and tried to be as accurate as possible.
The Atari ST version of Starbyte Super Soccer was released for Christmas 1991. The PC version as well. The Amiga version programmed by Swiss René Straub a few days later.
The game is clearly a German game. Starbyte had taken it out of the public domain and ported it first from Atari ST to Amiga. Credit for designing it gets Dirk Weigand. As a teenager he had worked on the predecessor Kicker and released his soccer manager in 1990/91 under a label that he called PolarSoftware. Kicker was one of the first German-language soccer management games. Weigand, who lives in Troisdorf (north of Bonn), was inspired by the 1984 Footballmanager on the ZX Spectrum and had developed his own football manager from 1987 on. His new football game was supposed to stand out from other comparable games with several new features.
Dirk Weigand owned an Atari 600XL and soon reached the limits of what was possible with it, as the computer only had 16 kilobytes of memory. He owes the progress in development to his „rich godparents from Switzerland“, who enabled him to buy an Atari ST for his confirmation. The game was programmed with GFA-Basic 2.0. Basic also made it possible to compile the software to an independent program. Brother Frank and stepfather Bernd helped at least conceptually and with constant testing. 16-color sprites were contributed by Oliver Merklinghaus. And Dirk Weigand won the listing of the month in Atari Magazine for the month of January 1989.
Start screen of Dirk Weigand’s soccer manager KICKER, which was released as shareware in 1990.
Completed in 1990, Kicker was first distributed and played only among acquaintances and friends. In the German computer magazine Aktueller Software Markt ASM 8+9/90, the game was then presented in a new column, and Weigand was contacted by the company Micropartner, which wanted to distribute the game. Since the company could not port the program, the deal fell through, and Weigand saw only the way of self-publication. The game could then be ordered from him as shareware program for 30 DM. Weigand remembers that he had about 100 orders in total. His Kicker was also included on some shareware CDs.
At the beginning of 1991 the German publisher Starbyte Software from Bochum contacted Dirk Weigand and made a deal with him. Besides the Atari ST version, the game should be ported to Amiga, PC and C64. At the end of 1991 the Atari ST, PC and Amiga versions were released. The C64 version was released one year later. Starbyte renamed the soccer management game with the new title Starbyte Super Soccer, which Weigand did not like. But keeping the title KICKER seemed not possible considering the biggest German football magazine at the time that was called KICKER. The new versions of the soccer management game were complemented with new graphics for the program start, music, and stadium sounds. The rest remained the same.
And this is the Swiss connection:The Amiga version of Starbyte Super Soccer was programmed by Swiss René Straub, who had already worked on other ports for Starbyte Software.
Start screen of Starbyte Super Soccer
The formation of the own team and the match tactics for each game are the heart of the soccer manager game. In Starbyte Super Soccer as in other similar games, the matches themselves are not visually shown or performed. Each time after finishing formation and tactics, the player gets a result and a report on the match.
In Starbyte Super Soccer, the player is allowed to take on the role of both manager and coach. And up to six players can take over their own teams at the same time; it just gets a little crowded in front of the computer. Weigand was at least proud of the review by popular game editor Heinrich Lenhardt, who ranked the game among the 100 best games in the 1991 Powerplay special issue and gave it an excellent 80% rating. But success was a long time coming, as two other football managers appeared almost simultaneously namely Bundesliga Manager Professional (1991) and Anstoss – der Fussballmanager (1993). And then, of course, there was the bankruptcy of the publisher Starbyte, so that the payments that were agreed upon in the contract, failed to materialize in 1992. From 1993 on, the game was then distributed by the re-founded company Starbyte Software. However, Weigand did not get much money. He had already written off the game and preferred to concentrate on his studies.
Not a good game for the Würzburger Kickers … – lineups, consequences and results are shown on the background of the field, followed by the table.
After more than 30 years Dirk Weigand was motivated again by an interview of Denis Roters about video game history. In 2021 he sat down again and went through the recovered source code of the old game KICKER and corrected an important bug in GFA Basic 2.0 which had hindered the start of the game in the emulator. So today, you can find a newly worked out disk image for Atari ST as well as emulations for various contemporary platforms on a very well documented website by Frank and Dirk Weigand.
(Beat Suter, CH-Ludens, 07.08.2023 / 17.08.2023)
Sources:
Denis Roters. Wie Starbyte Super Soccer in mein Leben kam. In: Videospielgeschichten, 25.04.2020.
LINEL was a software developer and publisher based in Switzerland. It had its headquarters in St.Gallen, Liechtenstein and Appenzell. The label was active from 1987 to 1995. LINEL was founded by seven or eight young Swiss developers in 1987. They focused on programming on Amiga and Atari ST but did some Commodore 64 ports and later DOS ports as well. Overall, 20 games were published with the label LINEL. Often, it was cooperation with other developer studios and publishers in the UK and in Germany.
Linel merchandize: a Swiss pocket knife for the publisher’s VIPs. Photo: Roman Werner
LINEL had some connections to other developers and publishers abroad from start on. Among the young developers, it was common practice to exchange information and visit each other and show what you were working on. Early on, the young Argovian devs around Heinz Lüem had invited devs for an exchange, and they came from the UK, Sweden, USA and Germany (Interview with Heinz Lüem by Larissa Wild and David Krummenacher, 2023). Likewise from 1989 on, Markus Grimmer invited many young devs to Appenzell, where he discussed concepts with them, and they worked on several games at the same time and helped each other out (Interview with Guido Henkel by Christian Schmidt und Gunnar Lott). For Grimmer, it was important to get deals with foreign publishers that could guarantee distribution of the games in countries like the UK, USA and D. So, it is not a surprise that cooperation with other studios and publishers took place almost from start on. And in later projects, LINEL always worked in mixed teams with devs from England, Germany; Scandinavia and Switzerland.
Collaborations
Mostly for publishing and distributing purposes, there were collaborations with the following companies (incomplete lists).
Logo used by Hewson Consultants from 1984 on.
Merit Software’s Logo from 1992-96
Frequent publisher collaborators:
Hewson Consultants Ltd. (UK) – Exolon (1987), Eliminator (1987) Players Software (UK) – Eliminator (1987) Merit Software (USA) – Traders: The Intergalactic Trading Game (1991), The Neverending Story II: The Arcade Game (1991) Software 2000 (D) – Der Schatz im Silbersee (1993) Softgold Computerspiele GmbH (D) – Kaiser Deluxe (1995) Clockwork Games Ltd. (UK) – Necronom (1991) Micro Deal Ltd. (UK) – Insanity Fight (1987) Pantheon Software (USA) – The Champ (1988) SYSTEM 4 de Espana S.A. (E) – The Champ (1988) Pactronics (AUS) – The Champ (1988) CCD (D) – Kaiser (1988) Codemasters (UK) – Maze Patrol (1987)
Frequent developer collaborators:
Dragonware Games (UK) – Exolon (1987) Nightrider Software (CH) – Dugger (1988), Crown (1989) 1001 Software Developments (NL) – Baby Bug (1989), Skate of the Art (1989) Lunatic Software (UK) – Necronom (1991) Cybervision (D) – Der Schatz im Silbersee (1993)
Unreleased Games
Some of the cooperation with other publishers and other dev teams didn’t work out. While we know of 20 games that were published with the label LINEL (See part 1) on many platforms, there were some games and projects that didn’t make it in the stores.
Is it already difficult to find and get information on some of LINEL’s published games that were done in collaboration with foreign publishers or international dev teams, it seems to be even harder to get enough information on abandoned game projects. But there are some announcements and in odd cases previews of prototype versions of planned releases that present enough information to list the games as unreleased LINEL projects.
An incomplete list:
Maze Patrol (1987)Dragonslayer (1988) Ice & Fire (1989) Crown (1989) Solaria (1989) Drachen von Laas (1989) Neverending Story II: Das Adventure (1991) Der Schatz im Silbersee (1994) Amiga version Durch die Wüste (1994)
Maze Patrol (1987) was a Commodore 64 game, that was due to be released by LINEL in 1987. Markus Grimmer commissioned the prolific Austrian Listing games designer Roland Mayer with a game that is said to be somewhat like his own Hungry Hoodlum (1987) game that was published by Tronic Verlag GmbH in Compute mit for C64 earlier in 1987. Mayer says that he received a call from Switzerland and was promised that his game would be published by LINEL for a good fee. He developed the game in Assembler, completed it and painted a title cover for Maze Patrol. It was a rather elaborate work that took him many weeks. But the game was never released by LINEL, nor was it released by Codemasters, a well-known English C64 publisher, LINEL tried to cooperate with at the time. Mayer does not know why the game wasn’t released. And he did not get any money either for his extensive work. Musician Helmut Melcher confirmed to researcher Lenny Bronstein (Games that weren’t: 64) in 2020 that they did a composition for Maze Patrol. “In the years 1987 – 1989, I did a few programming and games music jobs for LinEl. In April 4th 1987, I sent the music and music coding to Ronald. I still have a copy of the letter, and a printout of code and data. So: The music and its coding for MazePatrol on C64 stems from me.” (Melcher 2020) A copy of the game has not been found so far.
DragonSlayer (1988) by Christian A. Weber was a LINEL project that was announced for January 1989. French previews saw it as an extremely promising title by LINEL. Presentations were delayed and its first screens were finally revealed in November 1989. While gamers‘ expectations were high, the game’s incessant postponements put them to the test. The project was very ambitious. Again in 1990 french media announced the immediate release of DragonSlayer on Amiga, Atari ST and C64, but after that there was silence. It appears that some Dragon sequences have been used in a C64 demo of Rings of Medusa (1989). A few parts from the unreleased game were later used in the follow-up Rings of Medusa Gold. After LINEL had abandoned the project, Starbyte took over, assigned Chris Haller and Roland Petermann to the task and intended to make a Barbarian clone with the title Warrior of Darkness out of the DragonSlayer idea. But Warrior of Darkness faced the same fate at Starbyte and remained unreleased as well. However, Christian A. Weber managed to put a playable demo together on Amiga in 1991. And finally, Starbyte integrated a lot of material into its Rings of Medusa Gold (1994) Amiga version.
Dragonslayer sequence, that has been shared on English Amiga Board (2005). Sreenshot: DamienD
Ice & Fire (1989) was also announced in the Dugger booklet together with Dragonslayer as soon to follow release. The French magazine Generation 4 knows in its issue No.6 that the game is expected on Amiga and Atari ST. It had been announced as an adventure game with many original features such as offering several good endings.
Crown (1989) had been announced by the same French magazine Generation 4 as a strategy game reminiscent of Seven Cities Of Gold. “With almost 58 colors, the game, due for release on ST and Amiga in February 89, promises to be excellent.” The magazine prints one screen with a isometric map view of a city called Dead City showing the LINEL Logo as well as the title Crown.
Solaria (1989) was intended for release in March 1989. Again, the French magazine Generation 4 knows that it is a game that is based on an Aztec sport. Information on Solaria, Crown and Ice & Fire are sparse. Hopefully, there is more to find.
Drachen von Laas (not released in 1989) – a text adventure. The game was completed by the two German devs Guido Henkel and Hans-Jürgen Brändle, prior to signing a contract with Markus Grimmer, manager of LINEL. But the Swiss publisher favored the development of other games and delayed the release of Drachen von Laas over a year amidst money problems. After working on other projects, Henkel had enough in mid 1990 and annulated the contract with Grimmer. Although times were over for selling text adventures well and gamers wanted point’n’click adventures with visuals instead. The text adventure was eventually published by Henkel and Brändle themselves with their new label Attic Entertainment in 1991 for DOS, Amiga and Atari ST.
The release of Neverending Story II: the Arcade Game (1991) in early 1991 in German on Commodore 64 was followed by Amiga, Atari ST and PC versions in French, Italian and English. But the LINEL crew also worked on a a second installment, that was called Neverending Story II – the Adventure. This should have been the start of a classic adventure series. The development of this second game was going to be based on the new MACS engine (Modular Adventure Control System) that Arndt Hasch had developed for LINEL as an answer to Lucas Arts SCUM engine. Unfortunately, there was only a demo version, that made it to PC Joker and was previewed in their 6/91 issue. The reviewers were quite impressed by graphics and especially sound, but the game with the interface that looked rather similar to the classis Scum point’n’click adventures was never finished. Later, the MACS-engine was used for the game Der Schatz im Silbersee (1993).
Der Schatz im Silbersee (Amiga version, not released in 1993/94). The PC-Version was released in 1993 with Software 2000 as publisher. LINEL and Cybervision were the two developer teams, Markus Grimmer was the producer. Michael Tschögl did the animations. According to Mobygames, an Amiga version was developed, but never released. There is a demo version available in the internet. The German magazine Amiga Joker received a test-version and wrote a preview in its 3/94 issue and gave it a good rating of 74%. A first progess report was already written by Hans Ippisch in Amiga Joker 8/93. He visited LINEL and knew that the Amiga version will be similar to the PC-version, and it will come in 256 color graphics (for Amiga 1200). Ippisch’s progress report is worth reading since he describes in detail how script, storyboard and visuals were made. And he also gives some insights about contract negotiations at the Nürnberg book fair of 1992 between the head of the Karl-May-Verlag (books) and LINEL. Der Schatz im Silbersee was the first game by the German publisher Software 2000 of a planned Karl May Edition, a series of Karl May adventures that should have been developed with LINEL.
Durch die Wüste (announced but not released in 1994),would have been the second game in a series of three (or four) adventure games about Karl May. The magazine ASM received a sample version for PC, tested it and wrote a preview for its 6/94 issue. It mentions LINEL as developer and announces an Amiga version as well. The sample was from publisher Software 2000. The magazine knows that Durch die Wüste was structured in four episodes, in which the player as Kara Ben Nemsis together with his servant Ben Hadschi has to survive four different adventures. ASM also says that the graphics that it had seen so far leave it hoping for the best. It prints two screenshots from the game and praises the great scenery of which the game contains around 80, says that both characters can be controlled individually as player avatars. And the game contains many full-screen video sequences. Finally, it hopefully announces the release of a PC and an Amiga version for summer 1994. Sound programmer Matthias Steinwachs composed the music for the game. He got his assignment from LINEL-boss Markus Grimmer, who told him, the music for Durch die Wüste should sound oriental, but still oriented to western listening habits. Steinwachs did a thorough research and worked on it for several weeks. He was quite happy with his part and was waiting for the video sequences to finish his project. Unfortunately, they didn’t come – and the game was never released, and the series was abandoned.
The German Magazine Aktueller Software Markt (ASM) announces the expected second installment of a Karl May game series by LINEL in its 6/94 issue. Screen: Kultboy
Besides the 20 games, that Swiss publisher LINEL with temporary headquarters in St.Gallen, Arbon, Vaduz and Herisau had published under its own label in the years 1987 – 1995, there were at least nine more games or projects that had been completed but not released, or were in progress at some point and could be tested as prototypes, but did not make it further than being demo versions for the gaming mags. These games did not find their way onto the Software market.
LINEL was a software developer and publisher based in Switzerland. The label was active from 1987 to 1995. LINEL was founded by seven or eight young Swiss developers in the 1980s. They focused on programming on Amiga and Atari ST, but did some C64 ports and later DOS ports as well. Mobygames credits LINEL for 16 games. These are the following:
Insanity Fight (1987 on Amiga, Atari ST) Exolon (1987 on Amiga, Atari ST, Commodore 64…) Crack (1988 on Amiga) Dugger (1988 on Amiga, Atari ST) Eliminator (1988 on Amiga, Atari ST, Commodore 64…) Kaiser (1988 on DOS, Amiga, Atari ST) The Champ (1989 on Amiga, Commodore 64, ZX Spectrum) Baby Bug (1989 on Amiga) Skate of the Art (1989 on Amiga) The Neverending Story II: The Arcade Game (1990 on C64, Amiga, Atari ST, DOS) Necronom (1991 on Amiga) Traders: The Intergalactic Trading Game (1991 on DOS, Amiga, Atari ST) The Game of Life (1992 on DOS, Amiga) Der Schatz im Silbersee (1993 on DOS) Regent Deluxe (1994 on DOS) Kaiser Deluxe (1995 on DOS)
This Logo was used by LINEL from 1987 – 1993
The Website LemonAmiga comes up with three more LINEL games published on Amiga. For the first two there is only little public information available.
Gnome (1991 on Amiga) Kiro’s Quest (1992 on Amiga) Regent v.2.0 (1992 on Amiga)
And Lemoamiga dates a version of Kaiser on Amiga for 1989. Most likely the two different releases Regent v2.0 on Amiga and Regent Deluxe on DOS were similar versions of the same game, but the releases were three years apart and Regent Deluxe came as a remake with much better graphics and was completely done in German. All in all, so far, we know of 19 games published by LINEL Trading GmbH in a period of 9 years.
LINEL’s Logo for the years from 1993 – 1995
3 games were ported to other platforms: Exolon, Kaiser and Eliminator. 7 were developed by Swiss dev teams: Insanity Fight, Crack, Dugger, The Champ, Necronom, Traders and the Game of Life (The Golden Gate Crew). 2 games were developed by a small British team called Vision: Gnome, Kiro’s Quest. And 2 by a Dutch dev crew: Baby Bug, Skate of the Art. This leaves 4 games that were developed in mixed crews with German, Swiss and other devs, whereas some teams were bigger and had mostly German devs as for Der Schatz im Silbersee (Cybervision).
In 1989, LINEL signed a contract with two German developers, Guido Henkel and Hans-Jürgen Bräunle, to publish their game Drachen von Laas after the two fell out with German publisher Ariolasoft. The two developers called themselves Dragonware. LINEL is said to have been primarily interested in marketing the text adventure Ooze (also by Henkel and Brändle) in the UK and would have delayed the release of Drachen von Laas, so the two German developers terminated the contract in 1990 and eventually released the game under their own label Attic Entertainment.
From developer Guido Henkel also comes the information that he himself did the Amiga port of Kaiser in1989 for LINEL. Furthermore, LINEL was allowed to release the game Ooze on the British market at the same time with a new cover that impressed Henkel. All three UK-versions were published with the Dragonware label (not LINEL), but had LINEL’s address in Liechtenstein on the back of the box-cover, where they were produced at Merimpex AG.
Overall, we now know of 20 games, which the Swiss publisher LINEL with temporary headquarters in St.Gallen, Liechtenstein and Appenzell had published under its own label in the years 1987 – 1995.
Das Morgengrauen der deutschsprachigen Fussballmanager
Starbyte Super Soccer ist eines dieser frühen Fussball Management Spiele (Genre: Strategie). Der Name musste so gewählt werden, weil es andere Produkte mit demselben Namen Super Soccer gab, zum Beispiel von Nintendo. Starbyte selbst hatte bereits mit Soccer Manager Plus (1989) ein anderes Fussball Strategie Spiel im Angebot. Zwei Jahre später wurde fürs neue Fussballmanager Spiel ganz auf die deutsche Bundesliga gesetzt, die möglichst akkurat umgesetzt sein sollte.
Die Atari ST Version von Starbyte Super Soccer kam zu Weihnachten 1991 in die Läden. Die PC Version ebenfalls. Die vom Schweizer René Straub programmierte Amiga Version ein paar Tage später.
Das Spiel ist eindeutig ein deutsches Spiel. Starbyte hatte es aus der Public Domain geholt und zuerst von Atari ST auf Amiga portiert. Dirk Weigand hatte am Vorgänger Kicker gearbeitet und seinen Fussballmanager 1990/91 unter dem Label PolarSoftware herausgebracht. Kicker war einer der ersten deutschsprachigen Fussballmanager. Der in Troisdorf (nördlich von Bonn) lebende Weigand war inspiriert vom 1984 erschienenen Footballmanager auf dem ZX Spectrum und hatte von 1987 an seinen eigenen Fussballmanager entwickelt, der sich mit neuen Features von anderen vergleichbaren Spielen absetzen sollte. Dirk Weigand besass einen Atari 600XL und kam damit bald an die Grenzen des Möglichen, da der Computer lediglich 16 Kilobyte Speicher besass. Er verdankt die Fortschritte in der Entwicklung seinen «reichen Pateneltern aus der Schweiz», die ihm zur Konfirmation die Anschaffung eines Atari ST ermöglichten. Programmiert wurde das Spiel mit GFA-Basic 2.0 Das Basic ermöglichte auch das Kompilieren der Software zu einem eigenständigen Programm. Bruder Frank und Stiefvater Bernd halfen zumindest konzeptuell und beim ständigen Testen mit. 16-farbige Sprites wurden von Oliver Merklinghaus beigesteuert. Und Dirk Weigand gewann das Listing des Monats im Atari Magazin für den Monat Januar 1989.
Startbild von Dirk Weigands Fussballmanager KICKER, der als Shareware 1990 herauskam.
Das 1990 fertiggestellte Kicker wurde zuerst nur unter Bekannten und Freunden verteilt und gespielt. In der ASM 8+9/90 wurde das Spiel dann in einer neuen Kolumne vorgestellt und bei Weigand meldete sich die Firma Micropartner, die das Spiel vertreiben wollte. Da die Firma aber das Programm nicht portieren konnte, sah Weigand nur noch den Weg der Selbstpublikation. Man konnte das Spiel dann als Shareware für 30 DM bei ihm bestellen. Weigand hatte insgesamt etwa 100 Bestellungen. Kicker war ebenfalls auf einigen Shareware-CDs mit vertreten.
Zu Beginn von 1991 meldete sich Starbyte Software bei Weigand. Neben der Atari ST Version sollte das Spiel auf Amiga, PC und C64 portiert werden. Ende 1991 kamen denn auch die Atari ST, die PC und die Amiga Version heraus. Die C64 Version erschien erst ein Jahr später. Starbyte gab dem Fussballmanager den Titel Starbyte Super Soccer, was Weigand nicht gefiel. Ergänzt wurde es durch eine neue Grafik zum Programmstart, Musik und Stadiongeräusche. Der Rest blieb sich gleich.
Die Amiga Version wurde vom Schweizer René Straub programmiert, der bereits andere Portierungen für Starbyte erarbeitet hatte.
Startscreen von Starbyte Super Soccer
Die Aufstellung des eigenen Teams und die Matchtaktik für jedes Spiel ist das Herz des Fussballmanager Spiels. Die Spiele selber werden in Starbyte Super Soccer visuell nicht gezeigt.
In Starbyte Super Soccer darf der Spieler sowohl die Rolle des Managers als auch die des Trainers übernehmen. Und es können bis zu sechs Spieler gleichzeitig eigene Teams übernehmen, es wird einfach etwas eng vor dem Computer. Weigand war zumindest stolz auf die Kritik des beliebten Spieleredaktors Heinrich Lenhardt, der im Powerplay Sonderheft von 1991 das Spiel unter die 100 besten Spiele einreihte und mit ausgezeichneten 80% bewertete. Doch der Erfolg liess auf sich warten, denn fast zeitgleich erschienen zwei weitere Fussballmanager mit Bundesliga Manager Professional (1991) und Anstoss – der Fussballmanager (1993). Und dann kam natürlich noch die Pleite von Starbyte hinzu, so dass die vertraglich vereinbarten Zahlungen 1992 ausblieben. Das Spiel wurde dann ab 1993 von der neugegründeten Firma Starbyte Software weiter vertrieben. Viel Geld brachte es Weigand aber nicht ein. Er hatte das Spiel bereits abgeschrieben und konzentrierte sich fortan lieber auf sein Studium.
Kein gutes Spiel der Würzburger Kickers … – Aufstellungen und Resultate werden auf dem Hintergrund des Spielfeldes gezeigt, danach folgt die Tabelle.
Nach über 30 Jahren hat sich Dirk Weigand von einem Interview zur Videospielgeschichte nochmals motivieren lassen. 2021 hat er sich nochmals hingesetzt und den wieder gefundenen Source Code des alten Spiels KICKER durchgesehen und dabei auch noch einen wichtigen Bug im in GFA Basic 2.0 korrigiert, der den Start des Spiels im Emulator behindert hatte. Die Geschichte von Dirk Weigands Entwicklung ist in einem Interview von Denis Roters auf „Videospielgeschichten“ ausführlichst aufgeabreitet worden. Dazu kann man heute auf der gut dokumentierten Website von Frank und Dirk Weigand ein neu erarbeitetes Disk Image für Atari ST sowie Emulationen für verschiedene zeitgenössische Plattformen finden.
Der Control-Flow von 6502-Assembler (und viele andere auch) besteht letztlich aus JMPs und Register-abhängigen Branches (Vorgelagerte Vergleiche und implizite Vergleiche (INC,DEC) etc. Dadurch werden komplexeste Abfragen und Spruenge möglich (vgl. GOTO-Befehl in BASIC), die so gar nicht mehr heutigen vorallem Tree-basierten Ideen von Programmiersprachen entsprechen (vgl. C-ähnliche Sprachen). Die meisten Hochsprachen haben die Sprungbefehle abgeschafft und damit die Programme les- und beherrschbarer gemacht. Zum selben Problem gehören natuerlich auch die Sprungmarken. So muss im Assembler-Universum fuer jeden Sprung, Vergleich ein eineindeutiger Namen gefunden werden. An und fuer sich schon eine haessliche Sache, da interaktive digitale Welten von Vergleichen (If-Statements, For-Next, Loops) leben. (Selbstverständlich können moderne Assembler auch relative Sprungmarken verarbeiten wie etwa der KickAssembler – Nachfolgendes Beispiel).
Anders gesagt, die Möglichkeit zu Springen erweitert das Mögliche enorm und macht die Fehlersuche auch wiederum ungemein anspruchsvoll. Dennoch muss gesagt werden, dass Assembler Source-Code mehr nach einem Rhizom aussieht (einem Hin- und Her, einem Nutzen von Code mehrfach), als die linearsierte Form von Hochsprachen später.
Das Bild zeigt nicht unbedingt, was im Text diskutiert wird. Allerdings ist es hier auch möglich etwas nach comment_show zu springen, obwohl es linear gar nicht ausgefuehrt werden kann.
