Beautifully programmed games

Dave Batty · April 2007

Just watching the bobby bearing tzx and admiring the beautiful programming involved. Which other games would you say had asthetic programming opposed to functional programming (even though this may still make a great game)

e.g. Starquake - beautifully programmed no flaws at all
Fairlight - brilliant game and well programmed but flawed - pauses in between screens, no sound, slows up too much etc.

anyone get what I mean?

Collie · April 2007

This kind of question requires thought.

Unfortunately that rules me out from answering then.

Well until some others come up with some good examples.

Daren · April 2007

Most of Raff Cecco's games.

Jon Needle · April 2007

Hmm... games that are 'polished' in terms of it looks like the programmer(s) / level designer(s) had enough time getting things 'just right' rather than being forced to keep to unrealistic release schedules then

- the 16k Ultimate games
- Wizard's Lair
- Highway Encounter
- Zynaps
- Manic Miner (ingenious room designs)

Tbh, most of the games we considered great had that polished feel to them.

Then again, I loved Wanted: Monty Mole and still think it's a great game but it's flawed programming-wise. Being able to stand on any inked pixel? lol ;-)

Jon.

Geoff · April 2007

My favourite is 'Spindizzy' - good physics and ingenious landscape. I would love to see the algorithm for coding such a vast unrepetitive area.
And 'Elite' which I encountered on my brother's BBC B. Atmospheric, and probably better with wire frames than the later solid, rendered 3d.

dm_boozefreek · April 2007

Dizzy 1-3: Quality games, nice graphics, nice sound, no faults that I recall. 4 and up well they may have been consistent but I found em' a little sketchy compared to the first 3 (even though they added a ton of stuff to the game).

Jet Set Willy: You probably think I'm crazy saying this since the official release was riddled with bugs, so much so that the company that released it released pokes to fix the critical ones. There's also the non critical flaws that make this game so interesting, the Quirky Features so to speak (I know many people will disagree on this terminology). I'll admit I'm not a big fan of them but can negotiate them quite well, they can be an annoyance, but they can also be used as a tool for making bloody hard games.

Rex: Aesthetically pleasing and smooth.

Target Renegade: No complaints at all, Speccy version is probably the best ever.

Jack the Nipper 2 Coconut Capers: Fuckin' brilliant game, I also like the way you start in a different place every time (albeit it's a toss up between just a few).

Monty on the Run: The other Monty games are good (with the exception of impossashit), but I'd say this was Monty at his most perfect.

Ian Hamilton · April 2007

dm_boozefreek wrote: »

Monty on the Run: The other Monty games are good (with the exception of impossashit), but I'd say this was Monty at his most perfect.

I always preferred Auf Wiedersehen Monty myself. It has a lot of nice features like the aeroplane flying sequences and the little missions you have to complete (e.g. taking the steering wheel to Monaco and fixing the ski lift in Austria). I always found it easier to play than Monty On The Run too, which was far too difficult, for me anyway. :)

Necros.

48K · April 2007

Myth is very polished, as is Rex (although it suffers a little in slowdown at times). A lot of the Hewson games feel nice and polished too.

Costa Panayi's titles stand out also. (Deflector, Cyclone, Android 2, etc)

---

OT: first post in a while :-) Finally have wireless connection back up :-)

omega · April 2007

Sidewize, Crosswize - extremely smooth scrolly, great code (but hard to play)
Zynaps - superb
All games from Keith Burkhill (Ghost'n'goblins, Commando, Space harrier...)
Pete Cooke's Academy, Tau Ceti and Micronaut One
Chase HQ - superb code and design, I love it.

128k only games:
Carrier Command, Battle command
Where Time Stood Still

Metalbrain · April 2007

dm_boozefreek wrote: »

Target Renegade: No complaints at all

Target Renegade is an excellent game, but it has (at least) two bugs: the fragment of head's graphic appearing below when you perform a kick jump in the highest part of the screen, and in stage 4, if you're playing with two players and a dog kills one of the players' last life, that dog will start going up until the game crashes, unless the other player quickly kills it.

Jumping Stack · April 2007

Trapdoor has to be my shout. One of the main reasons for playing it is to unveil the next mad cartoon sequence that Don Priestley has chosen to involve you in.

Mighty_Zol · April 2007

I don't know a lot about assembly coding but for me, the Cybernoid games, (esp. Cybernoid II) are very polished.

Elite, brilliantly scaleable, a few well known quirks, but like JSW it sort of adds to the charm.

Head over Heels is pretty great in all aspects.

Metalbrain wrote: »

Target Renegade is an excellent game, but it has (at least) two bugs.

Agree it's a great game, handling 2 players and 5 quite large characters onscreen, however, on top of the bugs you mentioned it has a game-breaking bug on levels 2 & 5, where if you advance leaving the weapon behind and off the screen, all the enemies walk off and leave you, meaning you have to wait 2 x 6 minutes for the timer to run out and kill you, well either that or reload it.

TechnicianSi · April 2007

Head Over Heels without a doubt, although I could say that Batman had all the ingredients already there - Head Over Heels was just the natural evolution of Batman.

Sabre Wulf: Beautiful graphics, great sound effects and heaps of playabilty/replayability. Ultimates best game without a doubt.

Robin of the Wood: Flawless game imho. Superb music and speech (48k and 128k), great graphics and animation, bags of gameplay. One of my favourite games of all time.

Malc74 · April 2007

Most of the Dave Perry/Nick Bruty games are beautiful to look at, but perhaps not quite so much fun to play as most of the thought and programming effort seems to have gone in to the visuals rather than the game design or playability.

Shadow Warriors is a magnificent coin-op conversion - one of the very best on the Speccy, and beautiful to look at. Just such a pity that the programmers were forced to replicate the crapness of the arcade machine as well, though.

ewgf · April 2007

The Sentinel (obviously I would have thought), aside from the great playability, originality and graphics, the Spectrum version has the best sound out of every version I've seen - and how many other games can say that the Speccy version has the best sounds?

Also:

Skooldaze,
Back to Skool,
Dynamite Dan,
Dynamite Dan 2,
Starion,
Pyjamarama,
Herbert's Dummy Run,
Everyone's a Wally,
Three Weeks in Paradise,
Turbo Esprit,
Manic Miner,
Head Over Heels,
Commando,
The Great Escape,
Starglider 128 (I never played the 48K version),
Elite,
Infection,
Think!,
Split Personalities,
Brian Bloodaxe,

to name just a few.

WhizzBang · April 2007

I think that Lords Of Midnight is excellently programmed as it looks very polished and yet is huge in scope. When Mike Singleton expanded on the size for the sequal, it lost something in gameplay and presentation for me so I think the original balances things perfectly.

Bluce_Ree · April 2007

'Quazatron' always had a certain elegance to it.

Matt_B · April 2007

It's had to know what a "beautifully programmed" game is. I can think of lots of brilliantly designed and executed games, but for all I know the code behind them could look like a dog's breakfast.

obo · April 2007

I started just hacking games for pokes, but moved on to picking them apart to see how they worked. Some did seem to be quite a mess, but others were obviously very well structured. Starion and Starquake are the ones that stick in my mind most.

Starion's gameplay was a bit dull IMO, but the code was excellent. Aside from the full-screen countdown the vector graphics were the fastest around at the time. The line drawing was unrolled to all 8 possible directions, to be as fast as possible. The back buffer was cleared with the stack and after drawing it was copied to the display using the stack again. As expected, the vector calculations were done as fixed point with the low byte holding the fractional part. Trig used look-up tables with rotations done cummulatively rather than from scratch so visible errors crept in if not recalculated after a while. The ship data relied on most shapes being symmetrical for parallel drawing on each sides, though it didn't have to be used. All round it was the kind of things you'd expect from a Maths student/graduate. I even managed to extract enough of the whole engine to design my own shapes to rotate with the keyboard - might even still have a +D snapshot of it somewhere!

I remember Starquake for being very modular overall, so easy to hack and pick apart. Superb game too, with perfect use of colour and sound, and all running at a silky smooth 50Hz. The sprites were all drawn at the start of the interrupt, and using the stack so in-game Multiface snapshots could easily corrupt them. Interrupts were also re-enabled during their drawing, as it expected no further interrupt to occur until the next frame. Each of the scenery graphics had an 8x6 bit array for used squares, and were followed by 8 data and 1 attr byte for each used block. Room definitions just picked a graphic number and position. The bright bit was used for scenery collision detection rather than keeping track separately, with bright items being solid. If you reset the bright bit from a Multiface program (as I did) you can pass through everything! I remember extracting the sound effects routine too, which I didn't fully understand but I remember being surprisingly compact for the wide range of sounds it produced. I can't quite remember how many bytes defined each effect but I don't think it was more than about 10.

On the other side, I remember being horrified that Manic Miner and/or JSW use LDIR for moving around display data. They kept a copy of the empty room, and for each frame they would LDIR that to a working space, then add the sprites, then LDIR to the main screen. Early days I suppose, and the gameplay more than makes up for it ;-)

There were so many other great games that it's hard to know where to start listing them...

Si

rich_chandler · April 2007

obo wrote: »

I started just hacking games for pokes, but moved on to picking them apart to see how they worked. Some did seem to be quite a mess, but others were obviously very well structured. Starion and Starquake are the ones that stick in my mind most.

Starion's gameplay was a bit dull IMO, but the code was excellent. Aside from the full-screen countdown the vector graphics were the fastest around at the time. The line drawing was unrolled to all 8 possible directions, to be as fast as possible. The back buffer was cleared with the stack and after drawing it was copied to the display using the stack again. As expected, the vector calculations were done as fixed point with the low byte holding the fractional part. Trig used look-up tables with rotations done cummulatively rather than from scratch so visible errors crept in if not recalculated after a while. The ship data relied on most shapes being symmetrical for parallel drawing on each sides, though it didn't have to be used. All round it was the kind of things you'd expect from a Maths student/graduate. I even managed to extract enough of the whole engine to design my own shapes to rotate with the keyboard - might even still have a +D snapshot of it somewhere!

I remember Starquake for being very modular overall, so easy to hack and pick apart. Superb game too, with perfect use of colour and sound, and all running at a silky smooth 50Hz. The sprites were all drawn at the start of the interrupt, and using the stack so in-game Multiface snapshots could easily corrupt them. Interrupts were also re-enabled during their drawing, as it expected no further interrupt to occur until the next frame. Each of the scenery graphics had an 8x6 bit array for used squares, and were followed by 8 data and 1 attr byte for each used block. Room definitions just picked a graphic number and position. The bright bit was used for scenery collision detection rather than keeping track separately, with bright items being solid. If you reset the bright bit from a Multiface program (as I did) you can pass through everything! I remember extracting the sound effects routine too, which I didn't fully understand but I remember being surprisingly compact for the wide range of sounds it produced. I can't quite remember how many bytes defined each effect but I don't think it was more than about 10.

On the other side, I remember being horrified that Manic Miner and/or JSW use LDIR for moving around display data. They kept a copy of the empty room, and for each frame they would LDIR that to a working space, then add the sprites, then LDIR to the main screen. Early days I suppose, and the gameplay more than makes up for it ;-)

There were so many other great games that it's hard to know where to start listing them...

Si

Fascinating post...

Nick Elliott · April 2007

Starion sprang to mind when I first saw this post, as obo mentioned the vector graphics were really really smooth.

Sabre Wulf is another which I always loved the look of, so rich and 'luxurious'.

Oh, and Pete Cookes later games, you can tell he invested a lot of time in every detail, the game, the interface, they were complete in every way and very professional.

zxspecticle · April 2007

obo wrote: »

I started just hacking games for pokes, but moved on to picking them apart to see how they worked. Some did seem to be quite a mess, but others were obviously very well structured. Starion and Starquake are the ones that stick in my mind most.

Starion's gameplay was a bit dull IMO, but the code was excellent. Aside from the full-screen countdown the vector graphics were the fastest around at the time. The line drawing was unrolled to all 8 possible directions, to be as fast as possible. The back buffer was cleared with the stack and after drawing it was copied to the display using the stack again. As expected, the vector calculations were done as fixed point with the low byte holding the fractional part. Trig used look-up tables with rotations done cummulatively rather than from scratch so visible errors crept in if not recalculated after a while. The ship data relied on most shapes being symmetrical for parallel drawing on each sides, though it didn't have to be used. All round it was the kind of things you'd expect from a Maths student/graduate. I even managed to extract enough of the whole engine to design my own shapes to rotate with the keyboard - might even still have a +D snapshot of it somewhere!

I remember Starquake for being very modular overall, so easy to hack and pick apart. Superb game too, with perfect use of colour and sound, and all running at a silky smooth 50Hz. The sprites were all drawn at the start of the interrupt, and using the stack so in-game Multiface snapshots could easily corrupt them. Interrupts were also re-enabled during their drawing, as it expected no further interrupt to occur until the next frame. Each of the scenery graphics had an 8x6 bit array for used squares, and were followed by 8 data and 1 attr byte for each used block. Room definitions just picked a graphic number and position. The bright bit was used for scenery collision detection rather than keeping track separately, with bright items being solid. If you reset the bright bit from a Multiface program (as I did) you can pass through everything! I remember extracting the sound effects routine too, which I didn't fully understand but I remember being surprisingly compact for the wide range of sounds it produced. I can't quite remember how many bytes defined each effect but I don't think it was more than about 10.

On the other side, I remember being horrified that Manic Miner and/or JSW use LDIR for moving around display data. They kept a copy of the empty room, and for each frame they would LDIR that to a working space, then add the sprites, then LDIR to the main screen. Early days I suppose, and the gameplay more than makes up for it ;-)

There were so many other great games that it's hard to know where to start listing them...

Si

Great post - I love reading this kinda stuff!

I'm a massive fan of Joffa Smith's stuff. All of his games are polished and well programmed, especially his scrolling and sound routines. Although it received decent reviews at the time I think Firefly is incredibly underrated as people hardly mention it at all when talking about "classic" games.

ChuckieEgg · April 2007

obo wrote: »

I started just hacking games for pokes, but moved on to picking them apart to see how they worked. Some did seem to be quite a mess, but others were obviously very well structured. Starion and Starquake are the ones that stick in my mind most.

Starion's gameplay was a bit dull IMO, but the code was excellent. Aside from the full-screen countdown the vector graphics were the fastest around at the time. The line drawing was unrolled to all 8 possible directions, to be as fast as possible. The back buffer was cleared with the stack and after drawing it was copied to the display using the stack again. As expected, the vector calculations were done as fixed point with the low byte holding the fractional part. Trig used look-up tables with rotations done cummulatively rather than from scratch so visible errors crept in if not recalculated after a while. The ship data relied on most shapes being symmetrical for parallel drawing on each sides, though it didn't have to be used. All round it was the kind of things you'd expect from a Maths student/graduate. I even managed to extract enough of the whole engine to design my own shapes to rotate with the keyboard - might even still have a +D snapshot of it somewhere!

I remember Starquake for being very modular overall, so easy to hack and pick apart. Superb game too, with perfect use of colour and sound, and all running at a silky smooth 50Hz. The sprites were all drawn at the start of the interrupt, and using the stack so in-game Multiface snapshots could easily corrupt them. Interrupts were also re-enabled during their drawing, as it expected no further interrupt to occur until the next frame. Each of the scenery graphics had an 8x6 bit array for used squares, and were followed by 8 data and 1 attr byte for each used block. Room definitions just picked a graphic number and position. The bright bit was used for scenery collision detection rather than keeping track separately, with bright items being solid. If you reset the bright bit from a Multiface program (as I did) you can pass through everything! I remember extracting the sound effects routine too, which I didn't fully understand but I remember being surprisingly compact for the wide range of sounds it produced. I can't quite remember how many bytes defined each effect but I don't think it was more than about 10.

On the other side, I remember being horrified that Manic Miner and/or JSW use LDIR for moving around display data. They kept a copy of the empty room, and for each frame they would LDIR that to a working space, then add the sprites, then LDIR to the main screen. Early days I suppose, and the gameplay more than makes up for it ;-)

There were so many other great games that it's hard to know where to start listing them...

Si

really great post, pity it was about 7 miles above my head!

BloodBaz · April 2007

obo wrote: »

On the other side, I remember being horrified that Manic Miner and/or JSW use LDIR for moving around display data. They kept a copy of the empty room, and for each frame they would LDIR that to a working space, then add the sprites, then LDIR to the main screen. Early days I suppose, and the gameplay more than makes up for it ;-)

I am in agreement. I think Manic Miner was very inefficiently programmed esp. the double LDIR job. Thank god it only has to do it 2/3rds of the screen each time.

I am programming my own Manic Miner type game using the kind of sprite updates you describe in Starquake but I am not using BRIGHT attributes for distinguishing object types, I am using the attribute control buffer similar to Manic Miner (only 768 bytes and frees colours etc. for any kind of use).

I think Auf Weidersein Monty was a fantastic piece of software. Lots of masking in characters (behind and infront masking), even animating of general scenery. I am amazed they could do all this without screen tearing. The music was also fantastic and very easy to load in separately and play back via an interrupt routine (simply call an address 25 times a second etc...) Excellent example of modular, independant programming and making use of the 128K paging to ensure it doesn't interfere with the main program.

wokani · June 2007

obo wrote: »

I started just hacking games for pokes, but moved on to picking them apart to see how they worked. Some did seem to be quite a mess, but others were obviously very well structured. Starion and Starquake are the ones that stick in my mind most.

Starion's gameplay was a bit dull IMO, but the code was excellent. Aside from the full-screen countdown the vector graphics were the fastest around at the time. The line drawing was unrolled to all 8 possible directions, to be as fast as possible. The back buffer was cleared with the stack and after drawing it was copied to the display using the stack again. As expected, the vector calculations were done as fixed point with the low byte holding the fractional part. Trig used look-up tables with rotations done cummulatively rather than from scratch so visible errors crept in if not recalculated after a while. The ship data relied on most shapes being symmetrical for parallel drawing on each sides, though it didn't have to be used. All round it was the kind of things you'd expect from a Maths student/graduate. I even managed to extract enough of the whole engine to design my own shapes to rotate with the keyboard - might even still have a +D snapshot of it somewhere!

I remember Starquake for being very modular overall, so easy to hack and pick apart. Superb game too, with perfect use of colour and sound, and all running at a silky smooth 50Hz. The sprites were all drawn at the start of the interrupt, and using the stack so in-game Multiface snapshots could easily corrupt them. Interrupts were also re-enabled during their drawing, as it expected no further interrupt to occur until the next frame. Each of the scenery graphics had an 8x6 bit array for used squares, and were followed by 8 data and 1 attr byte for each used block. Room definitions just picked a graphic number and position. The bright bit was used for scenery collision detection rather than keeping track separately, with bright items being solid. If you reset the bright bit from a Multiface program (as I did) you can pass through everything! I remember extracting the sound effects routine too, which I didn't fully understand but I remember being surprisingly compact for the wide range of sounds it produced. I can't quite remember how many bytes defined each effect but I don't think it was more than about 10.

On the other side, I remember being horrified that Manic Miner and/or JSW use LDIR for moving around display data. They kept a copy of the empty room, and for each frame they would LDIR that to a working space, then add the sprites, then LDIR to the main screen. Early days I suppose, and the gameplay more than makes up for it ;-)

There were so many other great games that it's hard to know where to start listing them...

Si

This post is a jewel. I really enjoyed it alot as I am myself in the proccess of disassembling Green Beret.

Thanks,

Adriaan

Rickard · June 2007

wokani wrote: »

I really enjoyed it alot as I am myself in the proccess of disassembling Green Beret.

I am really looking forward to hear about it!

Fizza · June 2007

I think Stop The Express was a quite an advanced game and programmed really well, I can't get technical about it (although I'd enjoy it if someone more knowledgeable did), but it certainly looks great, especially for it's age too.

frobush · June 2007

wokani wrote: »

This post is a jewel. I really enjoyed it alot as I am myself in the proccess of disassembling Green Beret.

Thanks,

Adriaan

NO! Don't! Please don't!

ewgf · June 2007

Obo's post was very interesting, and showed the lengths that talented and hard working Spectrum programmers (or good programmers of any limited hardware) would go to to compensate for the host hardware's deficiencies, but imagine a similar post regarding a PC game;

The program is written in unrefined [Whatever language] with many duplications of routines and catch-overflow/error conditions, and the data is stored in an uncompressed state on the hard drive, with many replicated chunks of data and inexplicable gaps. The program makes no attempt to write directly to the hardware, instead using the most time-consuming entry points in the driver's database, and does everything by the book, utilising no time-saving tricks or known features. The program uses Windows functions for all calculations and and input/output, and makes no use of the advanced x86 functions on offer, nor does it compensate for the known x86 maths errors.

On the plus side, the newly released 184MB patch (v3.12) does have some nice graphics on the splash screen when you start it up. Plus it removes, in most circumstances, the bug that formats your hard drive when you click on "Start Game".

JuanF. Ramirez · June 2007

One of my favourites is Cobra: good music and smooth scroll

WhenIWasCruel · June 2007

"You're saying that only because Frobush is around".

Beautifully programmed games

Comments