Development of Blake's 7 (was OASIS development)

[ibisum]

What I think: the speech animations could be about 30% shorter than they are, and it'd still work. That's more important to me than SFX ..

[Chema]

Do you mean the time each sentence is displayed? I really think that is because English is your mother tongue Several non-native English speakers asked me for more time, so I increased it a bit.

But you gave me an idea... I could add a configure the speech speed menu: slow, normal, high

Do you think it could work?

[ibisum]

For sure its something that should be configured.

Also, see the thread on HN today, where OASIS has been discussed, and in particular the speed of the text was mentioned:

https://news.ycombinator.com/item?id=13016104

[Dbug]

In game audio is always difficult, and as you said, music tends to be annoying after a while, so let's throw some random ideas.

For the speech, maybe something like in Captain Blood: https://youtu.be/zCpvpYKn8Vk?t=237

To make scenes more alive, you could also have some of the non speaking characters just now and then change direction, or just their head bobbing to indicate they either listen, agree, disagree, are bored, etc... maybe just move the eyes, left, right, up, down, roll eyes when they can't believe what they are hearing.

For soundscape, maybe the dimmed sound of spaceships landing and leaving, announcement sounds about things happenings ("Ding-Dong: We remind travelers that bla bla bla"), drip of water from leaking plumbing, sqweeks of aliens rats, wind, waves, rain, somebody switching between different radios with just few seconds of music of different styles and then cutting it off?

If the player solves something, reaches a checkpoint, some enthusiastic "ta daaaaaa!!!!" to mark the event?

You can also cheat by inserting noisy corridors or connecting rooms that serves no purpose other than making the place feel alive: Corridor with a window, and in the background you see a spaceship leaving or entering, and the hero can comment on it.

End of random thrown ideas

[Chema]

I have already thought about some of your ideas, Dbug, others are refreshing and interesting. I promise I will give all them a chance (as I always do with everybody's suggestions). We have to be realistic, though. We don't have 128K of memory to keep dozens of animations, sounds and objects running. The extra animation frames, for instance, was one item in my TODO list (and still is) but I am quite on the limit on the graphic size for the main characters!

But, as the resource system seems to work quite well and I am still with 34K of space for data, I might well give it a second try later on.

However, I have added quite a few things here and there to give more life to some places, such as the main hallway. The animated cameras and the guard which randomly looks one side or another were already there, but now you can also look at the information screen for some interesting news. I also populated the last room with objects to interact with, etc.

And I have already some extra SFX for whenever the user picks something up or something is solved.

I think you'll also like how Vila follows you to introduce you to the rest of the characters without being intrusive and other nice details.

But what I have done this weekend is work on the menu and save/load feature, following your suggestion. The program detects if there is a saved game and, if there is not, directly falls to the main menu after the intro:

2016-11-27.png (9.6 KiB) Viewed 12106 times

This is the same one accesible though pressing ESC during the game. It temporary sets b/w picture, which is a nice detail in my oppinion:

As you can see the player can redefine the keys from here (still not implemented, though) and set the talking speed as ibisum suggested, and also the volume (silence, soft, normal and high). I also tweaked all the timers and how they were calculated so talking speed is much more reliably calculated and it is a bit faster even in the slowest option but also more constant.

One question here. Would you find it too problematic if the ESC key which brings up this menu and also serves as a pause is disabled during some cutscenes? In some cases I play with the screen, setting text or colors, and those are lost after removing the menu. I have no intention of reserving a bunch of memory just to dump the overwritten area to restore it later, so I just redraw the screen.

Back to the saving/loading, the game saves automatically whenever the player does something relevant (there is a scSave() script command for that). I have tried to test all the savepoints and they seem to work okay, but much more testing is still needed.

If there is a saved game, after the intro, the game shows this other menu, asking the user to Continue with the saved game or start a New one.

2016-11-27 (2).png (8.64 KiB) Viewed 12106 times

[ibisum]

Looks awesome, truly! I agree about the b/w mode-switch when ESC is pressed, even from the screenshot this looks very smooth and pro looking. My design-hat gets tweaked, a little, by the spacing of the in-game menu, though I imagine you're going to tweak this further at some point .. ?

About the ESC key usage during cut-scenes - will there be some other way to exit the cut-scene if necessary? I can imagine playing the game a fair bit, but not wanting to see the cut-scenes each time - for me, it would make sense that ESC during this state simply exits the playback of the cut-scene, and if I want to get to the menu further, I do it from a 'non-cut-scene' just as per normal.

Turning out to be quite a thrilling project, Chema - very much looking forward to booting up a real Atmos and giving this a try one day ..

[Dbug]

Probably a naive question, but why displaying the settings menu over the scene graphics?

If you display it over where the current game keywords (Give, Pickup, Use, ...) are displayed, you are not annoyed by the problem of redrawing the screen, it works both in game, and during cut scenes (which means you can even add a "skip cutscene" option if you want), but mostly it allows the player to actually see the nice pixel graphics while paused, and it hides the keywords which are not supposed to be active while you are in the menu

[Symoon]

I had the exact same thoughts about the menu position (though it being in the middle of the screen is nice indeed), and about the ESC key during cut-scenes. IIRC in Lucasfilm games, ESC did cut the cut-scenes ! So this double function would solve the display problem: ESC to leave the cut-scene, then ESC to pause the game.

[Chema]

Hi and thanks all for you input. A couple of details: ESC is used to skip the cutscenes. In fact it has been working since the very first versions. You know everything is done using script code, right? well there is a command which lets you specify an override offset, so whenever the user presses ESC the execution jumps to that offset. So it does not only work, but also in highly configurable (you can have several "skippable" sections in a cutscene).

That is also interfering with the menu, by the way, and one of the reasons why I have to decide what to do. Currently it is working as Symoon summarized.

The position of the menu is indeed a great idea. I did not put it in the lower section because it just "did not look right". I like how it resembles a kind of window covering the screen; however if it is better for usability, that is something which could be changed right away. Thanks for the idea.

@ibisum, if you could give me some advice about how to arrange things in a nicer way, I'll be glad! I know some tweaking is needed, but I usually struggle with a trial-error process until I somewhat like the result

Anyway the good news is that the system seems to be working! Nice, eh? Auto-saving, as Dbug said, gives the game a modern look if correctly done. I have detected a couple of glitches, probably due to uninitialized memory which retains old values when I reset the Oric (oricutron with F4), so that is my next task. The adjustment of speed in texts and having two speeds is a nice touch too, imho! I really want to include a way to redefine keys because using the cursors is a bit cumbersome in the Oric. At least for me.

Later on I'll check for joystick support.

Argh... and I forgot about the disk access speed problem. Any news on that? I simply don't have time to work on everything at the same time!

[Dbug]

Argh... and I forgot about the disk access speed problem. Any news on that? I simply don't have time to work on everything at the same time!

One of the things I forgot to ask: Are you loading files mostly sequentially, or are they spread over all the floppy?

[Chema]

I think mostly spread all over the disk. Although I tried to put everything I think I'll need in the same file whenever possible, so I may load up a room with all its objects, some strings and a couple of pics on the same file, say 80% of everything which is loaded, then when, needed more data that could be in another file(s) anywhere in disk.

[Dbug]

Ok, just trying to figure out: Generally speaking, it's the track change that is the most costly operation in the floppy operations because it needs to physically move the head.

[Chema]

Ah ok. I missed the point of your question then... It is taking long to load a big sequential file: the game engine. And it is about 16K. Then a tables section of a few Kb.

The thing is that even when reading sequentially it clearly takes too long. It is not just a small difference with the emulated thing, but people say it loads much quicker (equivalent blocks) from SEDORIC.

Without more serious testing, I cannot tell. The problem is that I just don't have time now for doing both the game and these tests, so if anybody could help...

*beg mode*

[Dbug]

My problem is that:
- I don't have a physically working 3" floppy drive, the one I had tried to learn flying in a demo party when somebody (drunk) dragged a power cable which made everything on the desk flying - including the brand new Mac Book of my neighbor who shattered its screen.
- I don't have any PC with a floppy drive that can be used to generate physical floppies.

That makes testing quite difficult.

If it was somewhat possible to modify the Cumulus firmware (or Oricutron) to add a "real spead" performance mode that simulate rotation speed, seek time, etc... complete with displaying information about where the head is, and emulated "toc toc toc toc zeeeeeeehhhhhhhh toc toc toc" sounds, that would help tremendously.

Regarding the Sedoric speed, would be interesting to test in identical circumstances: Try to load a 16 kbyte file into memory, using Sedoric, using FloppyBuilder with compression, using FloppyBluilder without compression, to identify if the cause is purely loading or related to the entire load and decompress code.

[Chema]

Yeah, that kind of tests is what I am talking about. I can work on them, or on the game, but have little time for both. Therefore, I was asking for help by somebody with a 3.5 floppy disk. I thought iss was doing his own tests in this area. Any results? I know I failed to even test his disk image a couple of pages back in this forum!

In any case, as soon as I move on into the game a bit further, I will have to face the Telestrat bug and probably work also on disk access, so everything will come with time... A LOT of time, unfortunately