Arcade Game Designer

[highrise]

Hello everyone

My name is Allan. I'm actually a z80 game coder, and I helped work on updating an engine for a game designer which uses a simple syntax to then assemble games into machine language. Originally it was exclusive to the ZX Spectrum, developed over many years by Jonathan Cauldwell, and dozens of excellent games have been written. The engine supports software sprites, room layouts and so on and is fast and easy to use even for beginners. I myself have completed three games which have been published. It's a great way for less experienced coders to create games, and is one of the reasons the Spectrum homebrew scene is so healthy.

Recently the engine has been converted to the 6502, and as a result dozens of games which were designed on the ZX Spectrum are now playable on the Acorn Atom and the BBC Micro. A 6809 engine is also in progress, with other machines under consideration.

I was recently playing a few games on the Vic, and it seems to me that the expanded (probably 32k) Vic would be a great machine to add so we're looking for someone interested in maybe joining our team to help with that. We're a very relaxed group, there is no pressure or deadlines, we just enjoy working together on the challenge and the excitement of seeing games written on one machine being converted to another without any change to the core code, because each system has its own compiler and engine. The system outputs source code in assembly which can then be built, or edited if you have the experience.

A full windows dev environment is also in the works, with the ability to test before compilation via a javascript engine.

To be clear - the 6502 engine is already working well, so any developer would mostly be looking at rewriting the graphics and sound routines to work with the Vic. An experienced 6502 coder shouldn't find this too tricky I don't imagine, and we are all willing to help.

here are a few example games built on the Spectrum.

Terrapins
https://www.youtube.com/watch?v=_8MvLtccgo8
Roust
https://www.youtube.com/watch?v=vTYKoJAWH6w
Nixy
https://www.youtube.com/watch?v=H7MGZJ60NFg
Temple of Lost Souls
https://www.youtube.com/watch?v=hRlBHwyFQ8w
Dead Flesh Boy
https://www.youtube.com/watch?v=cnG0u3GoJKE

[Mike]

Hi!

Those are particularly fine game examples you linked to in YouTube.

For the time being, similar games of course had been done on VIC-20 as well, quite recently Manic Miner had been ported to the VIC-20. Several projects use Robert Hurst's SSS (Software Sprite Stack) library or other, tailor-made solutions for sprite-like graphics.

So when it comes to available routines, the VIC-20 is quite well equipped with that.

However, ports from other machines quite often require a thorough re-design of the graphics data, mainly for resolution (just around 160..176 pixels width opposed to 256 on the ZX or 320 pixels as with the C64 and BBC) and also colour capability. Without a good deal of trickery, the video chip of the VIC-20 only allows for a single background colour (but still different colours for each text character cell); for more colourful graphics, multi-colour is employed which reduces the already smaller horizontal resolution again by half (two bits define one of four colours for a twice-wide pixel). People still can do nice graphics on the VIC-20 (take a look at MINIPAINT as a hosted tool for pixel artists), but it's a source of mismatch that prevents easy ports.

I suppose the C64 would be an easier target, but then the C64 has more hardware capabilities (hardware sprites and pixel-wise soft-scroll in particular) which probably aren't addressed by your engine. YMMV.

Anyhow, good work, and maybe the game ideas spark an incentive to port your games to the VIC-20 despite the added difficulty curve. With a "plain text" description of the game engine/rules it is surely easier to port the games as if the game logic would need to be inferred from assembly code or gameplay alone.

Greetings,

Michael

[ral-clan]

Although I cannot offer help, I would like to say that I was very impressed by the quality of the games produced. I was expecting something more simple and "cookie cutter", but these are as good as any commercial release for the VIC-20.

[beamrider]

Yes, the games look top tier.

I would like to help but I already have several unfinished Vic 20 projects that I can't even seem to get motivated for these days.

[Kakemoms]

Would be interesting if you could say more about how the graphics is implemented in your software. Is the 6502 version made for atari, apple or c64? How is raster timing implemented? Double buffering?

[Kweepa]

I suspect the resolution differences that Mike highlighted are a dealbreaker for this project.

[Kakemoms]

It would be a good moment to show that game playability has nothing to do with what graphics resolution it uses.

[Kweepa]

Well, duh... Manic Miner?
However, the idea here is to use shared game data files on several machines, and that's almost a non-starter.

[beamrider]

The current targets already have differing resolutions. E.g. BBC 320x256 and Spectrum 256x192?

[Kweepa]

Right, but the Spectrum is the 'home' system and the BBC is a superset, so it can still run the Spectrum games.

[beamrider]

Since the videos in the OP are only videos of Spectrum games, it is difficult to tell how the multi-platform targeting works.

Given your assertion, the BBC versions of the 'home/spectrum' games would look odd since only 80% (width) and 75% (height) of the screen estate would be consumed by the spectrum graphics assets.

It would be possible to abstract away the graphics layout into a virtual co-ordinate system with a lookup table for each target platform along with tailored assets.

Perhaps highrise would be kind enough to supply more technical details?

[highrise]

Hi guys

Thanks for the responses, sorry for the delay. I'll try to answer some of the questions. First of all, whilst I do own a Vic-20, I have next to no idea of its technical capabilities. My knowledge is mainly based on the games that I've played. So if you guys say it can't be done, i'll take your word for it. But I live in hope as I love homebrew on all machines.

Currently the 6502 engine runs on the BBC Micro and the Acorn Atom. The C64 is a consideration but it is well served with homebrew so at the moment we're talking to enthusiasts for machines with smaller homebrew libraries because the idea of dozens of new games is very appealing. Users of these machines also tend to be especially expert in them.

The Atom has a 252 x 192 monochrome screen mode, and also a 128 x 192 4 colour screen mode similar to the Tandy (which is also supported in the same way). When in lower res, the blocks and sprites are compressed in order to fit the design. Much of the game syntax is dependent on the initial resolution and block / sprite / tile sizes, so if you change the resolution, it's the game ENGINE which changes, not the actual syntax used. So for a game to work at a different resolution, you build an engine suited to it. For example, the Amstrad CPC has a resolution of 160 x 200, but it is pixel based, so it's possible for the sprites and blocks to also be made smaller in order to be cross-compatible. The blocks (tiles) on the Spectrum are 8 x 8, whereas on the Amstrad they are 5 x 8. So whilst code for drawing screens and testing blocks in the engine is different, the code syntax is basically the same because much of the scripting is based on these initially defined resolutions.

Another thing to remember is that many games don't use the full screen anyway - within AGD itself there is a game window which is the actual game resolution in chars. Some games use as little as say, a 128 x 128 screen, i.e 16 x 16 chars. Games of this type might be more suitable for adaptation.

Now, of course, I'm not going to pretend that a game can just be converted from one system to another without some effort - graphics and resolutions of course have to be adjusted, but much of the game logic remains the same. Converting a game from one system to another is not fully automated, but it is much, much easier than starting from scratch. To give you an idea of the process.

We start with an 'AGD' file which consists of a set of definitions - game window size, map, plus screen layouts, sprites, objects etc, along with a set of simple scripts which are run in what is a relatively simple loop, which essentially allows the screen to interact with the sprites and the sprites with each other, in order to make a game. It's a simple concept but it is highly flexible.

Each machine has an engine, which handles all the essential tasks according to the machine's specs, and a compiler, which converts the graphical data and the simple AGD scripts into pure assembly source code which are then integrated into the engine. The end result is full assembly source code for the game, which can then be altered by an experienced coder if they choose to, or assembled as is.

The other point I would make is that whilst not all games would be convertible, it would of course be possible to use all of the tools in order to create dedicated Vic-20 games as well.

I hope that gives you more of an idea. As I said, I know it may not be possible, but if one of you guys is intrigued enough to at least take a look at the concept we have 6502 experts in our team who would be happy to explain more. Certainly it would need someone with experience, but the results could potentially work the same wonders for the homebrew scene on the Vic as they have on the Spectrum. Here's hoping!

[cbmeeks]

TL;DR

Sorry, been lazy today and haven't read the entire thread.

But what you just said really appeals to me. I'd love to tinker around with some simple games. What would be awesome, IMHO, would be to release something like this on a 32K cart that supports saving the file to disk (real or SD2IEC).

[beamrider]

I thought the designer is hosted on a PC?

[highrise]

The original AGD ran on a 128k Spectrum, creating games for the 48k Spectrum. The new project is online / pc based. For example, the sprite editor we are working on is designed to be adaptable to a range of different machines and graphic modes. The end result from the editor is assembly source, but ultimately we want to also be able to link to an external assembler and emulator to allow the games to be run.