"It’s a reckoning": Worms 30th anniversary

In 2025, Cult game "Worms" by Team17 will have its 30th birthday. To celebrate the occasion, a new, free release of the game is planned - with levels created by the Amiga demo scene!

"Worms - The Directors Cut" (1997) cover artwork

According to sources (see end of article) "Worms" developer Andy Davidson has announced a reimagining of "Worms DC" ("Director's Cut") 1.5, that is set for release in January 2025, and for free. That's a very nice gift to the Amiga scene. 

Actually, he doesn't refer to the occasion a celebration, but a reckoning - which is quite fitting for the game.

To make the new release really special, Amiga demo groups are encouraged to submit their level designs, via a forum thread at amigans.net - which is a nice, and interesting idea. Graphics artists that are active in the demo scene have created some of the most stunning visuals ever seen on Amiga screens, so some eye candy can certainly be expected. "Worms" isn't a very complex game, but maybe, given the deep understanding of maths, bits, and bytes, in these circles, even some unusual, challenging designs might show up, that give the gameplay an unexpected twist.

"Worms - The Director's Cut" (1997) in-game screen

Basically, "Worms" levels are just bitmap images, so all that's required to create one is a paint program such as Deluxe Paint or Personal Paint. A couple of details regarding color palette and depth have to be respected, obviously. 

More details, and your place to submit your application (well, there's no specific process - just leave a note) can be found at this URL:

https://www.amigans.net/modules/news/article.php?storyid=3282

Additional sources:
http://amiga-news.de/de/news/AN-2024-10-00078-DE.html

AADevLog #5 - Will it become... a game?!

Creating your first action game from scratch can be quite a challenge, and cause severe frustration. But at some point you begin to see some light at the end of the tunnel - and that's where the real fun part begins.

My experiments in creating something that might become... a game?! ...have reached a stage where (except for sound) pretty much everything is in place: timing, user input, movement, graphics, limits, ...and it seems to work! Stably!

To achieve this within a somewhat tolerable time frame (= this lifetime), some fundamental decisions had to be made: 

- few colors

It turns out that Amiga color palette considerations can be very time consuming. To make progress, no attempts were made to max out the possibilities.

- single reference platform support

AGA compatibility has been dropped early on, OS3.x would be nice, but Kickstart 1.x support is a must for this project anyway (for personal reasons), so an Amiga 500 with Kickstart 1.3, OCS, 1MB RAM has become the single target platform. If possible, the... game? ...should fit into 512KB RAM. (256KB would be even better.)

- accept bad performance now, optimize later

This is something I really had to get into my head: It won't be fast! Not yet! Maybe never! I have a tendency to spend a lot of time thinking about loops, variable size, etc. without being sure the entire program architecture will work out. (Compare AA DevLog #0.) So to get a proof-of-concept of where and when things happen, the basic assumption was made that with some fundamental limitations set, the Amiga will somehow be able to handle the load within one, or at least two vertical screen refresh cycles, resulting in a usable frame rate. All other performance- or elegance-of-execution-considerations were dropped.

Everything still looks pretty... flat.

Well, despite my self-imposed rules, I still tried to make some routines scalable, reasonably "elegant" (?), or spent a little bit of time on thinking about speed. It just happens, and is part of the fun.

Having an ugly, but working prototype of the game, a level editor speeds up further development considerably. Creating the editor was comparably easy, as many of the functions required were already there from the game files.

Editing an NPC's path/waypoints

Now background tiles, foreground items, and non-player-characters (NPCs) can be easily added to the level - and as mentioned in the introduction, this put a broad smile on my face a couple of times. It's really fun to invent game mechanics - e.g. a path with waypoints for your NPC - and then be able to immediately see the effects in the game.

Thanks for reading, c u next time!

* * *

Click here for an overview of all AADevLog articles

AADevLog #2 - Sprites, tiles, scrolling... a game!

Another project I've been working on is slowly taking shape, and there was quite some headache involved to get it going.

In my pursuit of creating... a game! ...I've arrived at VSprites, tiles, and scrolling. The Amiga is a technical marvel, but it has it's pitfalls. So you read the docs, set up your default, low-res PAL display "View", create a "ViewPort", adjust ViewPort offsets, re-read the docs, adjust the ViewPort offsets properly, read the docs again, re-adjust... and it still behaves weirdly. At some point you try a high-res display mode. Either way, in the end result some VSprites are missing, or the scroll offset is wrong. Well, after hours and hours of experimenting, it turns out that ViewPort->RxOffset and ViewPort->RyOffset are indeed the correct variables that need to be changed to move around a larger source bitmap, but they get interpreted differently by different Kickstart/OS/chipset versions - it looks as if KS3.0 on AGA chipset, and KS3.1 SetPatch'd by OS3.9 on AGA chipset, might be messing up VSprites when scrolling, and earlier KS versions always scroll by low-res pixels, regardless of actual display (high) resolution. As a quick fix I'm focusing on what is probably still the most common Amiga configuration: Amiga 500, OCS chipset, Kickstart 1.3. I'll work on compatibility or maybe a separate version of the game later.

Basic screen mockup, to get an idea of object's sizes, and screen layout

And a "bug" in the docs was discovered: When using VSprites, you "reserve" some hardware sprites from VSprite usage by setting/clearing bits in GelsList->sprRsrvd. The docs give contradictory information about what "reserve" actually means - bit set or clear? It has now been proven and confirmed that bits need to be set to allow VSprite usage of that hardware sprite, and bits need to be cleared to "reserve" the corresponding hardware sprite from VSprite usage. Einstein-alike.

Anyway - after overcoming these obstacles it's beginning to look like... a game!

ViewPorts are a great thing, by the way. There are a couple of limitations, but whenever you run low on colors, need a different origin for your drawing coordinates, or maybe are thinking about an alternative to a dual-playfield, a new ViewPort might solve the problem.

So now it's got a scrollable bitmap, separate status bar, sprites, tiles, game map files, and a rudimentary "physics" engine that allows sideways movement and drops. That's a huuuge step forward!

No, that's not the... game! Just an early tileset.

Linux IFF picture viewer xiffview, which was created as a side-product of game development, now really comes in handy. I use it regularly, it has become part of my makefiles, and I add features as I need them.

When writing software that's handles data for different architectures, you have to pay attention to a lot of details. The reversed endianness (MSB on m68k vs. LSB on x86) has been mentioned many times. Also different compilers on different CPU architectures may have different data storage types - an "int" on a modern x86 machine is not be the same size as an "int" on Amiga. I encountered this just recently, when adding some code to xiffview that writes Amiga UWORD values to a text file, using something like fprintf("0x%04x", value). The UWORDs written had too many digits, too large for an Amiga 16-bit number. It looks like a bug on first sight, but the Linux x86 compiler is simply made to handle larger numbers (by default) than an Amiga C compiler. The solution is simple: you have to explicitly cast the value to a 16-bit data type, like this: fprintf("0x%04x", (short int) value).

Thanks for reading, c u next time!

* * *

Click here for an overview of all AADevLog articles

 

Sneak preview: Thrust is the way...

To be continued.

"Quasarius" - new oldskool arcade shoot-em-up for the Amiga

Do you like Space Invaders? Do you adore Deluxe Galaga? Do you remember Phoenix? Then this is the game for you!

https://ralizasoftware.neocities.org/images/quasarius6.png

Collect boni, earn extra ships, get the hi-score - Quasarius is a (very) classic Space Invaders type shoot-em-up game for Amiga by Raliza software. The graphics are simplistic, but perfectly moody, as is the soundtrack. "Quasarius" was written in BlitzBasic by Rafael Lima, with music provided by "Akira". It should run on any Amiga with at least 512KB RAM and OCS or above. (It has been reported that it doesn't run on Kickstart 1.3, though.)

You can download Quasarius for free from:
https://ralizasoftware.neocities.org/amiga.html

It's donationware, so consider making a donation if you like the game, encouraging the authors to continue developing for the Amiga. The developer already announced he's like to do a - probably (very) classic, too - side-scrolling beat-em-up game.

Here you can see Quasarius in action:

https://www.youtube.com/watch?v=C1FTDCHjdB8

Sources:
https://ralizasoftware.neocities.org/amiga.html
http://www.indieretronews.com/2017/06/quasarius-amiga-gets-very-arcade-like.html

AmiGameJam 2017 game development competition results

The AmiGameJam 2017 Amiga game development competition ran from February 5th to March 30th 2017, and was held in two categories: Classic OCS/AGA Amigas and Next-Gen Amigas (AROS, MorphOS and AmigaOS4). The theme was "TV Shows and Movies" or "Christmas".

Six titles were submitted: Brus Lii, Santa Run (Next-Gen/AmigaOS4), Easter Egg, Max Knight Xmas Edition, Bridge Strike, and The Last Starfighter.

Based on 140 ratings, submissions scored from 1717 to 4720 points.

And the winner is...

...Bridge Strike, a vertically scrolling shoot'em up.

Project R3D
Code: Pawel Nowak (juen)
Graphics: Krzysztof Matys (koyot1222)
Music: Simone Bernacchia (JMD)
Sound Effects: Marcin Swiech (doomer)

Congratulations!

https://img.itch.zone/aW1hZ2UvMTIzOTQzLzU3MDc5MS5wbmc=/347x500/sHD3hC.png

You can download Bridge Strike, and the other games made for the AmiGameJam at:
https://itch.io/jam/amigamejam/results


Sources:
http://amigamejam.ultimateamiga.co.uk/
https://itch.io/jam/amigamejam