Development of Blake's 7 (was OASIS development)

Want to talks about games you like, would like to see developed on the Oric, it's here.
User avatar
polluks
Pilot Officer
Posts: 65
Joined: Tue Jun 05, 2012 10:09 pm
Location: Germany
Contact:

Re: OASIS development

Post by polluks » Sat Sep 10, 2016 7:02 pm

Your masterpiece! 8)
cc65 development
Oric Atmos + Cumulus
Acorn Electron

User avatar
Chema
Game master
Posts: 2480
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: OASIS development

Post by Chema » Sun Sep 11, 2016 10:13 pm

Thanks for all the nice comments :)

I had some tough hours fighting the loading problem. I really wanted to find where the extra cycles were needed to make it work with real floppies and which were not necessary.

I came up with a version which works! I removed most of the waiting cycles which (I think) are not needed. The thing is that the extra waiting time that makes the difference is NOT anywhere where a pause is expected (to my knowledge).

Code: Select all

track_ok	
	; Chema: Here is the thing... the COLOR macro takes 14 cycles...
	ldy #3
waitcommand
	dey	;2
	bne waitcommand;2+1
	; = 16 cycles
	
	; Write the sector number in the FDC sector register
__auto__sector_index
	lda #loader_sector_position
	sta FDC_sector_register ;
	
	; Interdire les IRQ du fdc ICI !
	;lda #%10000101 			; on force les le Microdisk en side0, drive A ... Set le bit de données !!!
	lda #%10000100 			; on force les le Microdisk en side0, drive A ... Set le bit de données !!!
	sta FDC_flags
			
	;
	; Send a READSECTOR command
	;
	lda #CMD_ReadSector
	sta FDC_command_register
        ...
In all my tests the code to change track was never called, so just after reading the track register and checking the track is the one we want it jumps directly to track_ok above. And the pause of around 14 cycles must be put before issuing the Read Sector command. I have not the slightest idea why. But it works. And I removed nearly all the other waiting cycles (except those which are needed to comply with the controller specifications) and the loader works almost perfectly.

I made dozens of attempts and it always booted perfectly. I also tweaked the loader.asm a bit to retry if there was a read error (a branch if the status byte AND $1C is not zero). I think it is better to retry forever than do nothing.

This should also be done for the Track command. In Fabrice's code for Space:1999, 1337 and so, if the Track command fails, it restores track 0 and retries. Maybe this should also be done here, at least in the loader, so no wrong data is loaded into the game if there is some error.

Anyway I attach the modified sector2-microdisc.asm code. Dbug, if you could have a look maybe you'd like to test and consider updating FloppyBuilder.

Of course it still fails with a Telestrat, as the alignments are not done. I will try to fix that, but I have no Telestrat to test with. I also wonder if the code works with a Jasmin?

Now I need some kind of effect showing that the data is being loaded (even if just a text changing in color or something like that), because the boot time is longer with a real drive, and a black screen is... disturbing :)
sector_2-microdisc.zip
(4.39 KiB) Downloaded 176 times

User avatar
Chema
Game master
Posts: 2480
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: OASIS development

Post by Chema » Wed Sep 21, 2016 2:17 pm

After the first alpha testing round, I have already corrected many of the bugs and quirks. Still have some "todos" in my list, though.

I have also entered the last room for Episode 1 (accesible through door 2), but need to populate it with objects and things to interact with. Anyway the graphic is done, which is the worst part.

I also entered the cutscenes and final scenes for this episode and I am now waiting for the designs of some characters that appear there (currently re-using some I already have).

I need to think about a couple of things, such as how to deal with savegames. As I need to save the state of the virtual machine that means saving up to 48K of memory. You can subtract 8K if the screen is not saved, but redrawn (which has its implications, however) and probably more if empty memory is not included. Squeezing out resources and reloading them, is possible, though it may be a nightmare to be sure that everything is loaded and all pointers updated and not in an inconsistent state.

If, in the worst case, a snapshot of 40K is needed, it will occupy a lot on the game disk. Another disk could be used, but it won't be a SEDORIC disk (no support for that), so it will be difficult to backup.

I might go for a quick save/load on a fixed position in the game disk, but only one (if I have 40K free, that is) and a possibility to load/save to a number of slots on a different disk.

Thoughts?/Ideas?

User avatar
Dbug
Site Admin
Posts: 2985
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: OASIS development

Post by Dbug » Wed Sep 21, 2016 6:27 pm

In Little Big Adventure, I seem to remember that the game save files took less than 512 bytes: The game was saving automatically each time the player would transition to a new area, and despite using a lot of scripting all there was to save was a bunch of global variables and flags basically saying that you had this objects, you had activated this particularly important switch, etc...

So if I was you, I would reserve a small area in memory, say 256 bytes or something, and treat it as a globally accessible resource for the rest of your system, and make it so scripts work fine using only this data.

They can of course use local variables and other stuff to animate the current scene, but basically reloading a save game means to start with a clean sheet, a known inventory, a known set of important actions done by the player, and all the rest is inferred from there.

User avatar
Chema
Game master
Posts: 2480
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: OASIS development

Post by Chema » Wed Sep 21, 2016 10:13 pm

Yeah, storing just a small set of data from where the whole status could be rebuilt is certainly possible. The thing is that it is difficult, and requires code, that is, space.

All the objects active and in the inventory should be reloaded again, all the graphic and rest of the data, all the scripts, with their local data, the point where they were executing, timers... All without ending in an inconsistent state. Also all the internal pointers should be updated. Not permitting save games but at certain controlled points could help.

And what if resources should be loaded from different disks?

Don't know.. It is, of course, doable, but I need to think about it carefully.

User avatar
Dbug
Site Admin
Posts: 2985
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: OASIS development

Post by Dbug » Thu Sep 22, 2016 8:07 am

Generally speaking, mega save games are very fragile, it's what make many games fail to load old save games when patches and bug fixes are released, which make players infuriated. (I still remember how angry I was when after patching "Stalker: Shadow of Chernobyl" and "StarCraft II" I was unable to reload my old save games and had to start the game from scratch).

In term of code, that did not really make our scripting language much more complicated, it's just that we had two instructions to save variables, and two instructions to load then: One for the script locals, and one for the globals.

Thing is: The more you try to save stuff (mega save of everything) the hardest it gets to fix bugs.

If you save only what is important, it means that you can restart from a blank slate, which makes testing and tweaking a lot easier.

If you save your timers so all the characters stay at the place they were when you left, etc... it's cool, make the game very alive. It also means that any script that did something wrong at some point cannot be fixed: It may have allowed some stuff that should not have been possible, but now you are stuck with this character in this position or this variable set to that, which means adding more logic to make sure that does not happen.

In LBA, each time you change "room"; all the scripts starts from their first instruction, there's nothing remembered from what you did before, except these 256 something variables :)

User avatar
Chema
Game master
Posts: 2480
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: OASIS development

Post by Chema » Thu Sep 22, 2016 10:00 am

Dbug wrote: In LBA, each time you change "room"; all the scripts starts from their first instruction, there's nothing remembered from what you did before, except these 256 something variables :)
That could be an idea :) The same happens here with local scripts. But global scripts may be running. And that is something to be dealt with. Same goes for the object data which is stored in a huge array and the resources, which could be loaded back with some nightmarish adjustment of pointers and so.

But that means you can only save when you change rooms, so basically it is an automated thingy, not when the user decides, "okay, I am going to save here" in the middle of an action, dialogue, etc.

User avatar
Dbug
Site Admin
Posts: 2985
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: OASIS development

Post by Dbug » Thu Sep 22, 2016 10:16 am

Does not have to be "when changing rooms".
Could just be also when a major action is accomplished, when you change the global state.

Automatic saving has many advantages, one being that it makes the game look modern :D

The only important thing is to make sure that you don't get the player stuck in a broken state, and to make it obvious on screen that the game is saving so the player does not remove the floppy when this happens.

User avatar
Symoon
Archivist
Posts: 1695
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: OASIS development

Post by Symoon » Thu Sep 22, 2016 8:39 pm

Would it be possible to store somewhere and save the players actions, and when loading again, start from a fresh new game and replay the players actions at high speed with no display, and then go back to the game display - the environnement would be in the same state than when the game was saved?

Of course as you said, the big drawback is that this would require more specific code...

User avatar
Chema
Game master
Posts: 2480
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: OASIS development

Post by Chema » Sun Sep 25, 2016 1:34 pm

@Dbug I really like the idea of automatic saves. I prefer them over the usual save/select slot load/select slot. You need a different copy of the disk for a second player, but anyway. I am not sure if they will affect performance a bit (writing the disk is slow), but even saves could be ordered from the script code.

If I find a way to squeeze the needed save data to something around 2-3K (or less) and there is no need for a second game disk, I will give it a serious try :)

There are many things that could go wrong, as in OASIS there are global scripts that could be running all the time with timers or event synchronized, many pointers to things continuously being run (such as commands for objects - walk-talk...). There are even ways to modify the screen (writing text to it) without a way to store those changes (a redrawing would not re-write the text). However, if it is directed from the scripts, the programmer has the responsibility to handle those. And it may be possible.

@Symoon, I can't imagine how, to be honest.

On another matter today I made some good advances. First I found a bug that was appearing to some testers (Symoon, you are aware of it). It was the result of a series of actions which ended up with a memory leakage which, in turn, resulted in corrupted data. You had to made an interaction with an object which was not contemplated in the game, then do something which result in memory compaction (move to another room, then get back) and try a second interaction with the object (the object code was in memory, but the strings it used were not). I think I solved it, which is good. It was a hard one.

And the second interesting advance is that sfx are in at last!. The same system I used in Oricium, so they use the same engine as the music. I made just two tests, one is the step sound made by the engine itself, and the second one is the sound of the door opening/closing, which is launched within the script code (scPlaySFX(id) command).

Both seem to work perfectly, though the sounds themselves are crude and ugly (I can't show them yet, they are a bit horrible :) ). Now I am considering a couple of design aspects (such as if sfx packs are to be loaded from a resource or fixed in the game), but it is a good advance.

User avatar
Dbug
Site Admin
Posts: 2985
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: OASIS development

Post by Dbug » Sun Sep 25, 2016 2:57 pm

Chema wrote:@Dbug I really like the idea of automatic saves. I prefer them over the usual save/select slot load/select slot. You need a different copy of the disk for a second player, but anyway. I am not sure if they will affect performance a bit (writing the disk is slow), but even saves could be ordered from the script code.
You can still have the concept of slot, to allow for multiple players to play the same game.

Just say that you have 4 possible players, just reserve 4 blocks on disk, and let the player chose which one to play with.
If it's initialized, load it and continue, if it's not, ask the player to enter a name for the save.

Regarding the performance, I don't think there's any real speed difference between reading and writing, after all the disk rotation speed is constant.

It's slow with Sedoric because it will need to find where to write, bla bla bla, but in our system you already know where the data is going to be located, there's no directory content to update, no data structure to maintain, no linked sectors, and no fragmentation: Select track, select sector, write data :)
Chema wrote:If I find a way to squeeze the needed save data to something around 2-3K (or less) and there is no need for a second game disk, I will give it a serious try :)
Even if not using auto-saving, multiple floppies would still make saving a pain: You don't really want the player to play the toaster game.
That being said, assuming you have a two game floppies, I assume you would start the game on the first floppy, then continue on the second one, with no need to go back to the second one.
In which case, what would make sense is to have two full copies of the game on each floppy, with possibly just the intro missing from the second one, so you can boot directly on the second floppy when you are done with the first one.

The second floppy could also have a copy of the save slots, so when the player moves to the second disk you just save the status on the second floppy, so he can continue to play from that one :)

/me is just thinking out loud, may be totally lunatic.

User avatar
Chema
Game master
Posts: 2480
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: OASIS development

Post by Chema » Tue Sep 27, 2016 7:22 pm

More news. Today I received the designs for (among others) two main characters.

If Blake's 7 had something it was dark adult mood, great dialogue and one of the best evil characters ever: Supreme Commander Servalan, and her right arm Commander Travis.
00-lookRight.png
Travis
00-lookRight.png (626 Bytes) Viewed 8887 times
00-lookRight.png
Servalan
00-lookRight.png (626 Bytes) Viewed 8887 times
They both tirelessly pursue Blake and his men throughout the universe.

She is so cool, that the fan made this video (worth watching):

https://youtu.be/v5R5-NVvDMc

They are both already in the game, of course.

User avatar
Symoon
Archivist
Posts: 1695
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: OASIS development

Post by Symoon » Tue Sep 27, 2016 10:20 pm

Great graphics !
As for videos - I think I don't want to see any before playing the game... I spotted a few a couple of times, they look too dated and low-budget for me and I prefer having my imagination running when playing the game ;)

User avatar
ibisum
Wing Commander
Posts: 1117
Joined: Fri Apr 03, 2009 8:56 am

Re: OASIS development

Post by ibisum » Wed Oct 05, 2016 6:28 pm

Honestly, waiting for this game is very, very difficult. I feel like I'm 13-years old again, just dying for a new major release for the Oric sitting there .. waiting, waiting, waiting ..

User avatar
Chema
Game master
Posts: 2480
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: OASIS development

Post by Chema » Fri Oct 14, 2016 5:33 pm

I have designed a new character set (I confess I looked at some designs out there to get some inspiration) and put it inside the game. I did not use the character set generator, as I started before it was posted. I use Dbug's idea of a large bitmap strip and pictconv to generate the data. The great part is the easy it is to add/modify the designs.

I also made some more tweaks here and there and corrected bugs that were reported by some alpha testers.

This is a screenshot with the new character set. I hope you like it. It is quite more readable (back to a usual 6x8 font).
2016-10-14 (2).png

Post Reply