The 'skool' game core

[spider]

Skool Daze
Back To Skool
Contact Sam Cruise

I'm curious about this, I wonder if the authors aka the Reidy's and K.Warrington (graphics?) ever mentioned any plans to use this 'game engine core' for any more titles ?

I have not noted anything from the old magazines relating to this, even if it was perhaps a passing idea or a sketch rather than any code as such.

The 'engine' as such does have potential for more games...

[bluespikey]

It did have great potential for other games. But from interviews in Retrogamer, Skool Daze was written simply because the author wanted a game which asked geography and history questions (And wrote an entire school simulator to fit around it!). I can't find the reference but they were disappointed with the returns from Contact Sam Cruise and gave up on games after that.

[Juan F. Ramirez]

The 'engine' as such does have potential for more games...

Call me twat, but I've always seen a great potential there with an infiltration game. A mix Skool Daze + Saboteur

[clebin]

Call me twat

That definitely has potential as a follow-up to Call Me Psycho.

[PeteProdge]

Call me twat, but I've always seen a great potential there with an infiltration game. A mix Skool Daze + Saboteur

Throw in a bit of Wheelie too.

[Swainy]

Always thought that there should have been a third game called “Work Daze” with Eric working in a factory or something.

[lexi]

The way the 'skool' engine handles the player sprites is distinct from most other games i'm aware of - e.g. how sitting at a desk melds your sprite into the background layer seamlessly and you literally become a part of the school - a subtlety but one which boosts my sense of immersion considerably. I get that the more recent Skool Daze Reskooled was made with a lot of love, but it's somewhat paradoxical that that aspect cannot be recaptured outside of the limitations of the original colour clash.

I spent some time pouring over Skoolkids skooldaze disassemblies a few weeks ago and i had left with the impression that the layout and structure was created with intense intent by some advanced compiler or experienced team with a dozen games already published. Helen is credited with typing the code in from bits of paper with raw hex-values written by Dave - but how feasible is it to do that without gaining at least some understanding of the process? Like, she would have frequently had to save her work onto tape so probably didn't need Dave to put the tape in and press the record buttons for her each time If that were me, I'd want to load it up after to see if i'd made an error in transcription, or if there was a logical bug to report. Who was in the assembler making all the data/routine relocation decisions, etc?

Thinking about it more.. how likely is it that Helen deserves more credit than she's been given?

[ParadigmShifter]

Well there was no assembler it was all done by hand.

If Mr. Helen was nice he may have manually calculated a checksum I suppose otherwise I expect there would tears before bedtime if a typo was made.

EDIT: Or Helen could work out a checksum herself before typing in which was probably more likely lol.

EDIT: He was obviously good at programming though so I wonder why he didn't write his own assembler to make it easier for her? Or, you know, use one of the many assemblers available by that point lol.

EDIT2: I hope they didn't use tapes anyway

[lexi]

Always thought that there should have been a third game called “Work Daze” with Eric working in a factory or something.

I want this game. Find a way to get promoted to head office, then file TPS reports on time and stay late, or hide from mangers, smash printers without getting caught, etc.

Well there was no assembler it was all done by hand.

If Mr. Helen was nice he may have manually calculated a checksum I suppose otherwise I expect there would tears before bedtime if a typo was made.

EDIT: Or Helen could work out a checksum herself before typing in which was probably more likely lol.

EDIT: He was obviously good at programming though so I wonder why he didn't write his own assembler to make it easier for her? Or, you know, use one of the many assemblers available by that point lol.

EDIT2: I hope they didn't use tapes anyway

If you only have one computer, it totally makes sense for one person to debug routines on paper, while the other person efficiently handles the daily dev ops procedures, source control management, code assembly/linking, and then loading the tape at least once to make sure you have not made an obvious mistake. If you have multiple computers available, then that development process would be inexplicable.

This is coming from someone who learned to code purely from the process of typing in blurry 3rd-gen carbon-copied magazine listings my dad would bring home from work and then repeatedly being frustrated after an hour or so of laboriously typing in someone else's wrong code - that i learned to fix bugs myself. It's hard not to remember a dozen or so common hex codes when working at that level, but if i'm debugging on paper i'm going to be writing/debugging in some form of assembler notation and once done, writing the op-codes in the margin. Unless Mr Helen went into a trance and produced pristine a4 sheets with 80 column hand-written hex-codes, or took the extra time to write the hex codes on a separate sheet of paper from his working source - with very few mistakes - then yeah, she probably deserves more credit

I'm curious about the process, but not optimistic we'll ever know definitively.

[ParadigmShifter]

I think you may be overestimating the amount of "source control management" done in those days

Also linking probably wasn't a thing since you really need relocatable routines for that. Otherwise linking to a massive library can end up with a load of redundant (never called) code.

They did a good job though I will admit that, and not ending up divorced in the process lol

I think he probably budgeted space for routines so everything was easier to call (no relocation required if you know a routine will be at a certain address) and maybe went back nearer the end and filled unused space with other code/data. That's the only sensible way to do it I guess?

Obviously using an assembler which will work out jump offsets and labels would be a much better idea though.

[SkoolKid]

Unless Mr Helen went into a trance and produced pristine a4 sheets with 80 column hand-written hex-codes, or took the extra time to write the hex codes on a separate sheet of paper from his working source - with very few mistakes - then yeah, she probably deserves more credit

Because of the bug in Skool Daze's jumping sound effect routine - in which a byte value of 245 appears where there should be a 254 instead - I suspect that Mr Helen wrote the opcodes and operands in decimal, not hex. But was this digit transposition error his, or hers?

I'm curious about the process, but not optimistic we'll ever know definitively.

Yeah, I'd love to know more about it too. I did track down what I thought was Helen Reidy's e-mail address back in 2010, and sent a message about the skool disassemblies and Pyskool, but I never got a response. They are an elusive pair for sure.

[lexi]

I think you may be overestimating the amount of "source control management" done in those days

Really? She had to organise and manage and keep track of how many (hundreds? thousands?) of bits of paper all with different versions of routines, and the same routines with different dates/bugs/features... i'd take git over that any day. Even *shudders* SCCS. Just because it didn't have a job-title then, doesn't mean it wasn't labour.

Also linking probably wasn't a thing since you really need relocatable routines for that. Otherwise linking to a massive library can end up with a load of redundant (never called) code.

The interviews describe an iterative process where the Keith would come in on a daily/weekly basis with new art, and see it rapidly implemented along with other changes.

So yeah - you're going to need to have a way to to move routines/graphics/data around to make new stuff fit, and keep track of which routines reference them. If you're comfortable talking in op-codes then it's easily within your abilities to write an ldir utility routine which tracks and relinks those for you - and at that point I think an assembler would give you no additional benefit for its overhead?

Evidence for this may still be in the code.

Obviously using an assembler which will work out jump offsets and labels would be a much better idea though.

I disagree

I think he probably budgeted space for routines so everything was easier to call (no relocation required if you know a routine will be at a certain address) and maybe went back nearer the end and filled unused space with other code/data. That's the only sensible way to do it I guess?

I'd need to go back over the disassembly listings in order to speak more authoritatively on this, but I recall a lot of unused space in there. If everything was pre-planned/pre-allocated or if things were tidied up/compacted then I would expect it to look completely different - what is your opinion after studying the code?

[ParadigmShifter]

I've not studied the code obviously Skoolkid is the authority on this.

I was just saying they could fill in some unused stuff after the game was nearly finished if they wanted/could be arsed

My code uses aligned code and data all over the place so I fill in gaps as I go along once I am happy with a routine, moving stuff around to fill gaps and such.

Obviously I use an assembler and an emulator so it is easier though

[SkoolKid]

I was just saying they could fill in some unused stuff after the game was nearly finished if they wanted/could be arsed

There was definitely some of that going on. For example, try following the jump-aroundy path of these two routines:

• Print a character's title and name, and walk him onto the screen (1)
• Prepare a character to be walked onto the screen (1)

The memory map gives you a clearer idea of how these two routines (and others) are woven into the otherwise unused spaces between blocks of graphic data.

[lexi]

I've not studied the code obviously

Consider it homework

After almost 40 years, Skooldaze is still a assigning stealth-homework to kids

It did have great potential for other games. But from interviews in Retrogamer, Skool Daze was written simply because the author wanted a game which asked geography and history questions (And wrote an entire school simulator to fit around it!).

I want this to be true - I saw a reference to an 80s interview David Reidy gave to SU where he said something similar, but i'm not sure whether he was being entirely serious at the time?

[ParadigmShifter]

I had a look at the code ages ago and it seemed well designed from memory... lots of pointers to functions (or indices into a function lookup table) and such IIRC.

I'm a bit old to have homework seeing as I was a kid when it came out

Still a silly thing to do when he could obviously have written an assembler to make subsequent development much faster.

[Wizwords]

I've recently interviewed Keith Warrington for On The ZX Spectrum. It won't shed any light on many of the technical questions posed here (he was the artist) but might be of interest to some!