How big should new Speccy games be? 48k? Bigger? Release 2 versions?

[Lee Bee]

Greetings once more, folks! I'm back after my PC broke a few weeks ago!

(Apologies if this topic has already been discussed time and again. It's one of those topics that's tricky to search for.)

So… I was doing some AY music for an upcoming game by @gabriele amore. The actual game is under 48k, so I figured I'd have over 80k for the music, since it can only play on 128k machines. However, I then discovered he's releasing it solely as a 48k title, compatible with all models!

This has got me thinking about what's the ideal size to release a Speccy game these days? What is expected from the community?

Back in the late 80s, most games were released as a single 48k file compatible with all Spectrums. This is nice and simple, was quicker to produce and easier to manufacture. Plus, games back then didn't use too much AY music (which adds extra loading time for something 48k users can't hear).

But what about modern games? Is there such a thing as "standard practice" in 2024? These days it's very easy to release two files instead of one, each optimised for its respective machine. Do most developers even need to worry about 48k any more, since AY music is seen as standard? Or is 48k still seen as the "definitive" size for Speccy games?

[XTM]

I voted the first option, but I must admit I find a bit ridiculous to see such a large number of releases that say they are for 128k Spectrum, yet when you look at the actual game you don't really see why. They tend to be AGD games most of the time anyway, as there are very little non-AGD games released these days, and due to the nature of how these function (very often they are maze games, and usually much smaller mazes than in some of the 80s games like e.g. Starquake, Terminus, Project Future or Firelord, to list some examples) a lot of them aren't that huge in content that I'd think it would warrant using of a lot the 128k's memory banks. Yet most of them are labelled as 128k games, I guess this is mostly due to many of them having an AY tune playing.

[AndyC]

More memory doesn't necessarily have to mean more content. Some things can be faster by unrolling loops or using large lookup tables etc And C code is rarely the tightest on an 8-bit, so memory might be a fair trade for making development easier - it's not like people are earning a wage off it.

But ultimately, it should be up to the developers what they want to target. I don't really see why anyone else should be able to demand everything comes in a 48K version.

[Morkin]

I used a 48k and 128k toastrack extensively back in the day and appreciate both, but nowadays I do quite like seeing games that play on the 48k, so voted for that, just because it's a personal preference.

In-game AY music is often great to listen to for a bit, but I sometimes get a bit fed up of it and want to turn it off, especially if I'm playing for some time. And I also think you can be creative with 48k SFX (e.g. Dynamite Dan).

I guess you can fit in extra levels if you opt for 128k but I don't get very far in games nowadays anyway so it doesn't really matter to me

I didn't pick the first option because there's only one vote but of course I'm happy for the developer to choose, and I play most things on emulation so I wouldn't NOT play the game if it was 128k only (my emulator normally defaults to 128k mode anyway). I guess there may also be tech reasons why it's 128k only (e.g. needing shadow screens).

[1024MAK]

So… I was doing some AY music for an upcoming game by @gabriele amore. The actual game is under 48k, so I figured I'd have over 80k for the music, since it can only play on 128k machines.

Oi! My AY card for the rubber key / + Speccy says otherwise...

As this is a hobby, I went for option 1, it's the developers choice.

If we were going for the max, that would be a 128K system with multi-load off a Gotek with +3 or using a CF or SD memory card.

Mark

[Ralf]

It's up to the developer.
In my own games I do them for 48kB model but also include AY music
It's possible to play AY music on 48kB model. You don't need to modify the hardware and solder anything. You just need to connect a proper interface.
And on emulators, you usually also have some option like "AY sound in 48kB mode".

And if you don't have it, then playing AY won't break the game, it will just do nothing.

I do my games for 48kB because that's the model I owned and it defines nicely the scope of my projects. If you make games for 128kB or if
you make games reading data from disk then your project may become really huge (let's make Monkey Island for Zx Spectrum sort of things).
And such big projects have high chance of never being completed.

I also have some personal dislike for working with 128kB exclusive stuff like memory paging. I have seen once a thread that it's not only me, that
other people have it too.

So it's about your preferences and about your background. Russian coders make their programs for Pentagon as a default machine because that's what they actually owned in their young days and not "kosher" Spectrum from Uncle Clive.

[Lee Bee]

Some excellent points above! I particularly agree with Ralf that the appeal of a limited memory is that it helps keep projects simple and stress-free. Once you start trying to fill a whole 128k with graphics, it can seem daunting, like too much work.

On the other hand, as a musician, I find 80k very easy to fill with music. In fact, to me 80k seems like the perfect size for a game's soundtrack.

I think the perfect system would be a way of producing games so that the first 48k of code loads on any machine and contains the full game, but then there's a second block of AY music (up to 80k) which only loads on 128k machines. I wonder if anyone has ever released anything like this? I actually think this should be the standard for Speccy games. A 48k game + up to 80k of AY music.

[TakuikaNinja]

For me it's the following order from most to least desired:

1. Single version which runs as-is on 48K+AY & 128K
2. Single version which run as-is on 48K, but 128K adds AY music
3. Separate versions for 48K & 128K
4. One version only (I understand that it's ultimately up to the developer)

[equinox]

I see this as one form of the perennial "old or new" question. (Real hardware or emulator? Original Speccy or a Next? Playing all those itch.io new releases, or going back for another crack at Dynamite Dan? Nostalgia that keeps the machine alive for me, or evolution that might make it more interesting to others?)

Well, compatibility is nice, but personally I would like to see more big games with ambitious scope. Your example of Monkey Island is the sort of thing that could genuinely work well as a 128K-only multiload (gasp). It might even be near-acceptable on tape, since puzzle adventures are slow-moving and involve a lot of time spent in one region.

Having said that, I'm not very interested in systems that turbo-charge the Spectrum beyond what I see as Spectrum-like, e.g. whacking a big hard disk or a SID chip onto it.

[Turrican]

48K + AY with multiload.

[Lee Bee]

Your example of Monkey Island is the sort of thing that could genuinely work well as a 128K-only multiload (gasp). It might even be near-acceptable on tape, since puzzle adventures are slow-moving and involve a lot of time spent in one region.

Off-topic but I'm so up for Monkey Island on the Speccy! I've already done all the music in AY (example), and I know Adam would be able to provide superb graphics and has indicated he'd be up for it. So really all we need is a coder

[XTM]

... which you'll not get. Forget it. Hate to be the spoilsport, but we have seen this time and time again that coders won't turn up (I'm not saying it never happens, but it seems to be extremely rare). If you have graphics or sound and want something done, you need to start coding yourself. It's almost like an unwritten rule. The opposite seems to work out much more often.

[AndyC]

Monkey Island on the spectrum is pretty much a no go simply because of the lack of a standard disk interface. It would be worse than Street Fighter 2 levels of frustration trying to multiloads from tape. And that's long before you even start thinking about the problems graphics scaling and attributes would cause.

The Speccy gets more than it's fair share of "ambitious" titles, with things like Castlevania, Seraphina and Sword of Ianna. But those titles are a lot of effort for the coders in particular,l and the interesting coding tends to make up only a tiny percentage of that, so most of it can be a long slog fixing minor issues and coding fairly boilerplate stuff. It's why motivation drops off and some things never progress beyond a tech demo (the fun bit).

I'd rather see more coders takenon small projects and manage to complete them. Horace and the Spiders is still a fun game and well within the scope of a single developer doing a bit of after work coding.

[AndyC]

If you have graphics or sound and want something done, you need to start coding yourself. It's almost like an unwritten rule. The opposite seems to work out much more often.

It's a lot easier the other way around, that's why. A coder can get something achieved with crappy placeholder graphics and sound and then ask straightforward questions "I need you to produce X sprites, with the following dimensions, they can have Y frames of animation. Also the following restrictions apply...." and the results can be seen almost instantly.

What happens the other way around is typically over ambitious in scope, because the artist isn't a coder and doesn't understand where and what compromises have to be made. And then the coder turns round and goes "Nah, you're going to have to change all the characters to be X pixels shorter, the backgrounds need to use 32% less tiles and we're going to have to bin that fancy title screen everyone loves" and it starts feeling like a.critique of their work and a deviation from what they wanted in the first place. So do they carry on or walk away from the project hoping a better code will fulfill the vision?

[PROSM]

The Speccy gets more than it's fair share of "ambitious" titles, with things like Castlevania, Seraphina and Sword of Ianna. But those titles are a lot of effort for the coders in particular,l and the interesting coding tends to make up only a tiny percentage of that, so most of it can be a long slog fixing minor issues and coding fairly boilerplate stuff. It's why motivation drops off and some things never progress beyond a tech demo (the fun bit).

I'd rather see more coders takenon small projects and manage to complete them. Horace and the Spiders is still a fun game and well within the scope of a single developer doing a bit of after work coding.

Absolutely - 90% of the program is going to be relatively dull to write - translating all of the game-play logic into code can get tedious, never mind all of the routines for menus, score handling, different control schemes, etc. I know a lot of that can be broken into reusable parts, but there's always the work of adapting it to the current project as well. The interesting bits of designing the game and testing new ideas for graphics/sound routines are a pretty small part of the overall process.

That's why I've tended to prefer writing 16K arcade-style games; there's a natural limitation of scope when you've only got 9K of usable memory, and instead of creating a sizeable assortment of unique screens, you just need a solid set of rules to govern how the game handles and progresses.

[toot_toot]

48K was considered too small by the end of the Spectrum’s original lifespan, with many games being 128K only. So why go backwards? Make the most of the extra memory and AY capabilities!

In fact, seeing as I’d imagine most people play via emulation, make the game files larger. Build it around the +3 and make use of the 180K floppy disk space.

[spider]

It's a lot easier the other way around, that's why. A coder can get something achieved with crappy placeholder graphics and sound and then ask straightforward questions "I need you to produce X sprites, with the following dimensions, they can have Y frames of animation. Also the following restrictions apply...." and the results can be seen almost instantly.

Completely agree with this as said the other way around then the coder finds its not going to work, whereas the coder can (as said) simply stick any old nonsense into the sprite data areas etc to check the code/logic is functional, then worry about making it "look nice" later.


In regard to memory itself, not -that- many games did fully use all 128K, I think of a few where there were perhaps a few extra screens and maybe they used a page to redisplay the loading screen during the game menu etc, really "filling the space a bit" , not to disrepect anyone at all with that comment.


Myself, well it might sound a bit strange but the past few months or longer I've been more interested in what could be done in a 16K speccy.

[equinox]

Myself, well it might sound a bit strange but the past few months or longer I've been more interested in what could be done in a 16K speccy.

It's rather telling that the poll on this thread doesn't offer 16K as an option, isn't it?

[spider]

It's rather telling that the poll on this thread doesn't offer 16K as an option, isn't it?

I'm half hoping it was merely overlooked perhaps, but its fine either way.

[Ralf]

Speaking of the cooperation between a coder and an artist...

Doing a hobby, not-profit project in a team of several people bears extra challenges.
First of all someone may quit. Get bored or occupied with real life. It happens. Or maybe he doesn't quit totally but will promise some stuff
and never deliver it. Delaying it further and further which is even worse.

And believe me, finishing a job after someone is not nice at all. He had his own ideas and style, you have your own ideas and style.

Let's say that there is a chance of 20% that one guy quits. Not so much you can say. But in a team of 4 person a chance that nobody quits is
0,8 ^ 4 which is just 0,4096. There is 60% of chance that someone quits.

And artists are often capricious people They may draw some stuff that won't fit you from a coding point of view, as the others said. If you tell them to
redraw it, they will get offended and leave.

I believe all these "psychological" issues are a smaller problem if you are teenage kids, mates from the same school and neighbourhood writing your dream game. After all. you can talk all the differences over a beer. But if you are adult guys with your own busy lives who don't know each other in real life then it's unfortunately very probable that any collaboration project will fall apart.

[catmeows]

Or even better:
Day 1: You join a super ambitious projects of an arcade conversion after a previous coder left. He stated he has problem with drinking and is not able to continue on the project. But at least he sends you source code of his work as TRD image for some obscure russian assembler you never heard of.
Day 30: You worked through the code of your predecessor. It is commented in language you don't understand and you have barely idea what is going on in most of code. You decide to start with clean sheet.
Day 40: You inspect the graphics provided and do some calculations. It is very clear that artists have no idea how much space the graphics takes and you would need Sam Coupe with 256KB to fit everything in memory.
Day 60: You convice the artists that they really need to push number of tiles under 256 per level, if the thing should ever fly.
Day 80: You start do some coding. Not for demo, just to see how many of these super big sprites you can push on screen without flicker and with reasonable framerate.
Day 100: Artists manage to limit number of tiles to exactly 256 per level. So now just the tiles eat about 40KB of memory.
Day 110: Artists keep to add more and more animations for sprites. All memory saved on tiles is consumed already.
Day 150: Development thread on forum is super hyped.
Day 200: You tried lot of dead ends. Finally you have a solution that would radically cut memory footprint without hurting performance too much. But it is not like you have completed the game. You just solved one part of problem.
Day 230: Famous AY musians provides perfect conversion of arcade tunes. The music is amazing but it also eats up about 30KB of precious memory. You check your excel sheet where you keep track memory usage. The numbers doesn't add up.
Day 235: Now you understand frustration of the guys who converted Street Fighter II.
Day 250: You start to play with idea that YOU could start to drink. A lot.
Day 270: You made decission you would need split the game to two separate 128K loads. You don't see any other option. This has also impact on your code. Perhaps you could re evaluate your approach, now when memory constrains are lifted. At all, artists and musician provided top notch resources. You should do your best too.
Day 280: You decide you want really long break from the project.
Day 330: Someone leaks a video with loading screen and music from the project. No idea who did it, but you feel someone starts to be impatient. Development thread is overhyped again.
Day 400: You are back on project and you go through your notes.
Day 420: You start to rewrite your tools and start to implement memory management routines.
Day 450: Development thread is super hyped again. You reading through it and you realized you were kicked off from project and a famous name is the new coder. Perhaps they could send you PM but whatever.
Day 451: Development thread is super toxic. People blame you (ok) and compare you to some other coders of commercial era who failed to deliver. You feel that it is unfair, you are hobbyist, not a paid professional.
Day 455: You change your nickname on forum.
Day 480: The famous coder release a tech demo. It is super similar to demo you had about day 80.
Day 3000: The project is still in development hell. You are happy that you are not part of that project anymore.

This is not a true story.

[Timmy]

I guess most of my releases up till now, if not all, were 48K. Because I just liked them to be small.

That said, I started with a toastrack, so I could just release 128K games as well.

But it's just less likely because I still remember the days of loading for 15 minutes for a full 128K game.

On the other hand, I am likely to start making games for the toastrack because sometimes I just wish I had memory for just some more screens, and for now I just end up making really nice and small games instead.

Probably also needing more than 1 joystick button too, but I guess there's no standard for that yet.

[1024MAK]

And artists are often capricious people They may draw some stuff that won't fit you from a coding point of view, as the others said. If you tell them to
redraw it, they will get offended and leave.

That's it, I'm done with this, I quit, you can finish this topic on your own...

Mark

PS just teasing

[Dr beep]

My ACES project started in 2011. Got a hard bug that stopped the project. In 2016
the bug was solved but the original idea is partly lost.

Still did some progress but project is again on hold since 2020.

[Morkin]

not-a-true-story-yet-oddly-specific

And artists are often capricious people They may draw some stuff that won't fit you from a coding point of view, as the others said. If you tell them to
redraw it, they will get offended and leave.

That's it, I'm done with this, I quit, you can finish this topic on your own...