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

[Ralf]

This is not a true story.

Yeah, sure

[Joefish]

Let's face it, you can write a 48K game that pushes that particular machine spec way beyond what anyone would have said was impossible, but there's always going to be someone ready to give you a crappy review because he had a +2A and your game isn't playing incessant AY lift music like he thinks it should.

[equinox]

Let's face it, you can write a 48K game that pushes that particular machine spec way beyond what anyone would have said was impossible, but there's always going to be someone ready to give you a crappy review if it doesn't play incessant AY lift music in his emulator left on '+2A' mode.

But so enraging when a Speccy-clueless "multi format comparison" video loads the Spectrum version in 48K mode and assumes it has no music...

[Joefish]

But so enraging when a Speccy-clueless "multi format comparison" video loads the Spectrum version in 48K mode and assumes it has no music...

I think the trick is to sabotage it. The mistake is trying to pander to these people. There were plenty of perfectly legitimate ways to program a 48K that would crash a 128. So then it would just be more authentic. Or it could just detect the extra memory and tell you to **** OFF.

I made Buzzsaw+ able to work on Pentagon machines and let it be downloaded for free. Still there are uncountable 'cracked' and 'hacked' and 'Pentagon-fixed' versions of it with other 'crewz' names on it being passed around on Russian disk compilations.

As for the other way round, make the 'anti-piracy' security system play a tune and it won't let you start the game until you name it. Bit like that crappy bit with the rocket in Myst that you have to be a maestro with perfect hearing pitch to get past!

[Lee Bee]

Personally, I find it so easy to start projects and never finish them, though with me it's not because of inter-personal problems. I work well with others - just I have an ADHD brain that's constantly want to generate new ideas and meet new challenges, which means I have many projects (both big and small) "in development" (or sitting on the shelf).

Though lately I've been trying to make a big push to get some completed! Which reminds me, once @gabriele amore's game is finished in the next few days, I must finish the music for @RMartins's game, and the Telebugs game I've begun with @catmeows. I've also got to finish my complete Double Dragon soundtrack for @Swainy, which is nearly done. I also need to finish my complete Rodland soundtrack which I said I'd send to @Ralf just in case he could add it to his awesome Rodland mod (If successful, perhaps the game should be renamed to Modland). I guess this is all just a "note to self" here!

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

I'm pretty sure this was a joke, but just so we're clear…

While I can absolutely see the appeal of 16k, and why some developers might be happy only using 16k, this poll is about what you think the "standard size" should be for modern games. It ain't ever gonna be 16k!

48K was considered too small by the end of the Spectrum’s original lifespan, with many games being 128K only. So why go backwards? […] Build it around the +3 and make use of the 180K floppy disk space.

My favourite reply of the thread! This is something I hadn't considered but you are absolutely right and you make a compelling argument. By 1985, the Spectrum had evolved to 128k, and by 1987, 180k was possible with +3 disks. Nearly 40 years later, why would we "downgrade" the Spectrum? Shouldn't developers be free to use any size up to 180k if they wish? Yes, most developers won't need it, but if you wanted a game with lots of music or "pictures", 180k would be a lovely size.

[Lee Bee]

Loading engine idea

OK I'm now seriously thinking that this whole complicated issue could be resolved, and everyone satisfied, if some clever soul could create a (small) new loading engine that would become standard for most future Spectrum games…

The engine gives you 48k (or 16k) of code/main graphics - this loads on all machines.

You then have an optional second data block (up to 80k) which loads on 128k machines. This may contain ONLY AY music and/or "pictures" (i.e. large static rectangular images, never sprites). These "pictures" can be called in the code with a simple function, for example:

 Picture ( picture number , x coordinate , y coordinate , optional code for what to do if machine is 48k)

If the final parameter is missing, a 48k machine will do nothing here at all.

[equinox]

Loading engine idea

OK I'm now seriously thinking that this whole complicated issue could be resolved, and everyone satisfied, if some clever soul could create a (small) new loading engine that would become standard for most future Spectrum games…

The engine gives you 48k (or 16k) of code/main graphics - this loads on all machines.

You then have an optional second data block (up to 80k) which loads on 128k machines. This may contain ONLY AY music and/or "pictures" (i.e. large static rectangular images, never sprites). These "pictures" can be called in the code with a simple function, for example:

 Picture ( picture number , x coordinate , y coordinate , optional code for what to do if machine is 48k)

If the final parameter is missing, a 48k machine will do nothing here at all.

Eh, this seems rather limiting: good for certain action games only. It would be no good for text adventures, or 3D, or games (e.g. puzzles) that use the same graphics but have many different maps or level layouts.

[Lee Bee]

Eh, this seems rather limiting: good for certain action games only. It would be no good for text adventures, or 3D, or games (e.g. puzzles) that use the same graphics but have many different maps or level layouts.

Hmm, I don't understand why. Wouldn't this be perfect for text adventures? The 128k version could have more images, which are replaced in the 48k version either with a smaller number of more generic images, or no image at all in some cases.

[equinox]

Hmm, I don't understand why. Wouldn't this be perfect for text adventures? The 128k version could have more images, which are replaced in the 48k version either with a smaller number of more generic images, or no image at all in some cases.

No, think text-only adventures that use the space for elaborate description.
Or a game like Driller, which isn't made of prepared rectangular clip-art, but real-time calculated vectors.
Or Gauntlet: The Deeper Dungeons, which uses the same sprites all the time, but keeps loading more levels.

[Lee Bee]

No, think text-only adventures that use the space for elaborate description.

Or a game like Driller, which isn't made of prepared rectangular clip-art, but real-time calculated vectors.

You seem to be describing games which don't need more than 48k? The engine is obviously not needed for this.

[EdToo]

I can certainly see benefits in this DAAD ready has a 48k text only option for adventures and 128k option which stores images in the extra banks. There doesn't seem to be any reason why such an engine could be coded to use the 128k banks for a wide range of purposes, extra sprite animations, music, static images, etc. A single solution won't suit every case but could suit a wide variety.

[Lee Bee]

There doesn't seem to be any reason why such an engine could be coded to use the 128k banks for a wide range of purposes, extra sprite animations, music, static images, etc.

I suggested limiting the extra 80k to "music and pictures" because it means your actual game will be identical on all machines, with only one version of the game to worry about coding (and testing) instead of two. Simple is better. Plus, if you could fill the extra 80k with hundreds more sprites and animations, that's quite a daunting prospect and too much for most developers. (As has been noted, many developers like the limitation of just 16k. It's comforting and stress-free.) So, only allowing the 80k to contain "music and pictures" sets the data bank apart as something removed from the actual game - something you don't need to even worry about until after the game is finished, and then you can choose to add a few "enhancements" if you have time.

[catmeows]

For me, it is similar to movies. Some movies have 2 hours and you feel it is the right lenght, some other have 1 hour 20 minutes and you feel it is the right length. And then you have movies that ask for 2 hours and you feel they should be cut to 90 minutes. And also opposite, there are some movies are best seen in extended version.
And I think it is similar to games. Some games suits to 48K machine while other really should target 128K only.

[equinox]

You seem to be describing games which don't need more than 48k? The engine is obviously not needed for this.

No, look at the text adventure (no graphics) Unhallowed for example. It won't run on a 48.

[equinox]

I suggested limiting the extra 80k to "music and pictures" because it means your actual game will be identical on all machines, with only one version of the game to worry about coding (and testing) instead of two. Simple is better. Plus, if you could fill the extra 80k with hundreds more sprites and animations, that's quite a daunting prospect and too much for most developers. (As has been noted, many developers like the limitation of just 16k. It's comforting and stress-free.) So, only allowing the 80k to contain "music and pictures" sets the data bank apart as something removed from the actual game - something you don't need to even worry about until after the game is finished, and then you can choose to add a few "enhancements" if you have time.

The problem is that this kind of restriction means that people will develop a lot of similar lookalike games, which soon get boring. I think someone in this thread (? or another current one) already pointed out how much of an AGD glut there is. I've seen it mocked on a C64 forum too, how every new Speccy game is an AGD one. lol.

[Lethargeek]

I suggested limiting the extra 80k to "music and pictures" because it means your actual game will be identical on all machines, with only one version of the game to worry about coding (and testing) instead of two. Simple is better.

Singleload is better than multiload. If ANY kind of data fits into the extra 80k, why not using it? Even if the page switching is abused for the each byte extracted without any buffering it still would be many times faster than reloading from tape.

[equinox]

For fun: here is (a portion of) how messy it gets when
- you want your game to work on all Speccy platforms, but
- you need a BASIC control program for your USRs (so you can't stomp on +3DOS and reclaim those pages)
- it's too big for a 48K (requires multiload)
- it will fit in the 128/+2 RAM disk entirely (no multiload)
- it won't fit in the +2a/+3 RAM disk due to +3DOS eating some of it... so you have to do selective ERASE in real time
- 128/+2 uses the SAVE! RAM syntax but +2a/+3 uses SAVE "m:"
- and you only really know BASIC 'cause you are a lamer

(The variable m is a combination of PEEK 2899 and 23611, determining not only whether we are a 128 machine but whether we are currently in 128 mode so the RAM disk syntax is available...) And string l$ is the list of "which worlds are currently loaded" so that we can shuffle out the last one, to make room.

[TakuikaNinja]

The problem is that this kind of restriction means that people will develop a lot of similar lookalike games, which soon get boring. I think someone in this thread (? or another current one) already pointed out how much of an AGD glut there is. I've seen it mocked on a C64 forum too, how every new Speccy game is an AGD one. lol.

That was the second post in this thread, pointing out how 128K games tend to be made with AGD and only add AY music.

[equinox]

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

I'm pretty sure this was a joke, but just so we're clear… While I can absolutely see the appeal of 16k, and why some developers might be happy only using 16k, this poll is about what you think the "standard size" should be for modern games. It ain't ever gonna be 16k!

It was an observation. Your original post says: "Do most developers even need to worry about 48k any more?"
Replace that "48k" with "16k", and consider that nobody uses 16k any more. This could answer your question, in a sense.
Except that (I suppose because of the number of people who bought a 48k) we see the 48 as a 'necessary' platform and the 128 as a luxury optional extra.

(This is a fantastic thread, btw. I know I've been quite loud on it. But lots of really interesting opinions coming from all angles.)

[AndyC]

That was the second post in this thread, pointing out how 128K games tend to be made with AGD and only add AY music.

That's not how I read that post. It's saying a lot of 128K only AGD games are being made where the only reason for requiring a 128 is some unnecessary AY music. Which is probably true for a lot of modern games, simply because AGD allows a lot of less experienced people to build games and people tend to think they need music to make it feel finished.

[XTM]

The prospect of having 80k for music (and pictures) as pointed out by Lee Bee sounds interesting. This could immensely help immersion with the game IF the various tunes are made to fit the scenario/feel of the area/scene you are currently playing. Which sadly often isn't the case. As an example that has stuck in my mind - Hakkenkast, a game in a medieval/knight setting with techno style music. Even though games without music feel a bit empty, I'd rather have no music than this kind of mismatch.

Of course I know the dilemma. Most Speccy games these days are just a hobby project made in someone's spare time, plus often free and you don't look a gift horse in the mouth (insert "shrug" emote here, which this forum sadly lacks).

[equinox]

(insert "shrug" emote here, which this forum sadly lacks).

¯\_(ツ)_/¯

It's Extend Mode + Symb Shift + ¬

[Nienn Heskil]

Year 2024 A.D. The 'spectrum community' still hates 128K

[Lee Bee]

Hey @equinox, good points. Don't get me wrong, I'm not suggesting that everyone must use this engine, and developers can't use more than 48k for code and sprites if they wish.

I'm merely proposing a standard go-to model that would work well for most developers and tick a lot of boxes for most of this community. A community who—generally speaking—likes having limited RAM for coding and sprites, and appreciate compatibility with 48k machines, but who also wouldn't mind the flexibility to have more AY music for 128k machines.

The problem is that this kind of restriction means that people will develop a lot of similar lookalike games, which soon get boring.

I agree that any kind of engine can foster a trend of unoriginal lookalike games, due to the limitations engines impose. But actually, I don't see my engine as being limiting, I see it as being liberating - giving small games more music, and big games more compatibility, bringing the community together more. Any "trends" that arose from this would be welcome ones, IMHO.

[Joefish]

By 1985, the Spectrum had evolved to 128k, and by 1987, 180k was possible with +3 disks. Nearly 40 years later, why would we "downgrade" the Spectrum? Shouldn't developers be free to use any size up to 180k if they wish? Yes, most developers won't need it, but if you wanted a game with lots of music or "pictures", 180k would be a lovely size.

Developers can do what they want. What I think is a bit pathetic is reviewers criticising a game designed to run on a 41-year-old machine for not supporting the features of a 38-year old machine instead. Sure a 128 has a better spec, but then so does an Amiga. If you want a better specced game, get an XBox. Other retro scenes don't get this narkiness. How many C64 games get criticised for not having extra C128 features? I get that there may even be a majority of modern Speccy fans who started with a +2 box set, but that's not where it started.