Development of Blake's 7 (was OASIS development)

[Dbug]

Looks good
Just pointing out, using macros would help scripting, you can use the ":" symbol to have multiple statement on the same line to do something a bit like that (not tested, may not work 100%, just for the idea):

#define ENTITY_PLAYER 0
#define ENTITY_BOX 2

#define OPTION_LOOKAT(script) .byt VERB_LOOKAT : .word script-res_start
#define OPTION_OPEN(script) .byt VERB_OPEN : .word script-res_start
#define OPTION_CLOSE(script) .byt VERB_CLOSE : .word script-res_start
#define OPTION_END .byt $ff

#define ACTION_TALK(object,message) .byt SC_ACTOR_TALK, object, message, SC_STOP_SCRIPT
#define ACTION_OPEN(object) .byt SC_ACTOR_ANIMSTATE, object, 1, SC_STOP_SCRIPT
#define ACTION_CLOSE(object) .byt SC_ACTOR_ANIMSTATE, object, 0, SC_STOP_SCRIPT

#define START_CODE(type) .( .byt type| $80 :.word res_end-res_start+4 : .byt 2 : res_start
#define END_CODE res_end .)

START_CODE(RESOURCE_OBJECTCODE)
OPTION_LOOKAT(rlookat)
OPTION_OPEN(ropen)
OPTION_CLOSE(rclose)
OPTION_END
rlookat ACTION_TALK(ENTITY_BOX,MESSAGE_CARDBOX_BOX)
ropen ACTION_OPEN(ENTITY_BOX)
rclose ACTION_CLOSE(ENTITY_BOX)
END_CODE

[Chema]

Thanks everyone!

Dbug, that idea is fantastic. I always fail to remember using macros for this kind of things... Thanks.

[Dbug]

I'm now wondering if it would be possible to do something even more nastier
No idea if that would ever work, but what about:

Code: Select all

#define ENTITY_PLAYER 0
#define ENTITY_BOX 2

#define OPTION_LOOKAT(script) .( .byt VERB_LOOKAT,command_end-command_start : command_start : script : command_end .) 
#define OPTION_OPEN(script)   .( .byt VERB_OPEN,command_end-command_start : command_start : script : command_end .) 
#define OPTION_CLOSE(script)  .( .byt VERB_CLOSE,command_end-command_start : command_start : script : command_end .) 

#define ACTION_TALK(object,message) .byt SC_ACTOR_TALK, object, message
#define ACTION_OPEN(object) .byt SC_ACTOR_ANIMSTATE, object, 1
#define ACTION_CLOSE(object) .byt SC_ACTOR_ANIMSTATE, object, 0

#define START_CODE(type) .( .byt type| $80 :.word res_end-res_start+4 : .byt 2 : res_start
#define END_CODE .byt $ff : res_end .)

START_CODE(RESOURCE_OBJECTCODE)
 OPTION_LOOKAT(ACTION_TALK(ENTITY_BOX,MESSAGE_CARDBOX_BOX))
 OPTION_OPEN(ACTION_OPEN(ENTITY_BOX))
 OPTION_CLOSE(ACTION_CLOSE(ENTITY_BOX))
END_CODE

So instead of having a list of verb/pointers, you get verb/size/data, and you just use the size to jump over the data - assuming the data are less than 256 bytes long you actually get two bytes less per option (one size byte instead of a pointer, and no need for the end of script command since you know the size).

Just thinking out loud

[Godzil]

Stupid question, but why not use '{' or '[' instead of '.(' ?

[Chema]

XA syntax... .( opens a new context for labels, spanning up to the matching .)

[Chema]

Really nice idea Dbug!. However, I am not sure about implementing the 2nd option... For what I saw even in older SCUMM engines, these offsets are 2 byte long. I don't know if scripts larger than 256 bytes are going to appear, but until I start doing something more complex, I will keep the current layout for the time being (which is the one used in SCUMM BTW). There will be time for changes later, I guess.

Anyway I am not at that point yet. I am afraid that writing by hand all that code will be exhausting. I am really frightened about having to write a kind of compiler for that, but alas! I see myself writing an room editor too! able to handle everything I need, such as AIC graphics but also optimizing for tiles, adding walkboxes, objects and other data, and exporting all these to create the game data. A bit overwhelming, really.

But little steps. I am more concentrated on the skeleton of the engine and, more precisely now, with the user interaction. I know the "cursor" is not beautiful and it is slow and flickering at some times. The speed is something I am concerned with most, because it could ruin the playing experience. I plan to accelerate the movement if you keep the cursor pressed for some time, but I will have to check how that looks like. The flickering is quite inevitable, only hiding it by synchronizing with the vertical retrace is possible.

I also plan to add some kind of highlight of the verb when you move the cursor over it. I need to be careful with using attributes or they will be corrupted by the cursor movement. Maybe highlighting them when the cursor is over them, but removing the attribute as soon as part of the cursor is outside... that won't look good (the center of the cursor could be over the verb while it is not highlighted), but might work.

But that won't work with the inventory, where the selected item should remain highlighted. Maybe using inverse flags here could do the trick.

More importantly I have to implement more instructions of the scripting language but first try to find an optimum way for coding instructions (more precisely their addressing modes). Also the camera can follow a given actor if instructed to do so (there is a script command for that) by scrolling the room. This is working nicely, but is also quite crude: scrolling is slow. I have to implement more camera commands, so you could pan it to a given X position, or go instantly (with no scrolling), but also need some nice effects: fading is not possible, I think, but other effects could be thought of.

I don't know even how to dump a room graphic for a start. Having inverse bits on here and there would make the trick of setting ink and paper to the same value and change it when the room has been drawn, quite useless.

And the thing about loading resources from disk is driving me a bit mad. I have not even started with tests, but I already think there will be issues here. I will probably write you, Dbug, asking for help and ideas about how to organize things on disk. And that is just part of the story. Resources are loaded and discarded on demand, which means memory fragmentation. I have put some extra information on resources to help with compaction, but still need to implement the system. If a resource is moved, some pointers need to be adjusted here and there. I have some ideas, but problems will appear for sure.

Ah, nobody said this one would be easy. It reminds me a lot when I started working on an isometric engine. A lot of time passed from the first tech demos to a working engine and even more to produce a game with it (having to write some tools in the process, such as the map editor :/ ). And good old Twi was there to do the graphics and sfx!

[Dbug]

Really nice idea Dbug!. However, I am not sure about implementing the 2nd option... For what I saw even in older SCUMM engines, these offsets are 2 byte long. I don't know if scripts larger than 256 bytes are going to appear, but until I start doing something more complex, I will keep the current layout for the time being (which is the one used in SCUMM BTW). There will be time for changes later, I guess.

Still possible to encode things with multiple byte encoding: If size is larger than 128, then read another byte and combine
I'm mostly pointing that out because you were saying originally that memory would be tight. Just providing options!

I see myself writing an room editor too!

The advantage of the editor (running on a PC) is that you can easily start from an easy to manipulate set of data, and then optimize and tweak the output for whatever game/platform you need. Would also make it easier for other people to make game if they want to .
Can probably even run the emulator from the tool to check if needed.

I know the "cursor" is not beautiful and it is slow and flickering at some times. The speed is something I am concerned with most, because it could ruin the playing experience.

Does the cursor need to be handled like a mouse, could it not just smartly move on the closest interactable element on the left/right/above/below?
The interesting things in the adventure games has never been to find out the one clickable pixel hidden in some complicated pixel art structure, but more in finding how to use things to progress.
That would also solve the problem of corrupting the bitmap: If you have full control of where things are displayed, then you can have custom routines for various types of objects/background.

scrolling is slow.

I can have a look

I will probably write you, Dbug, asking for help and ideas about how to organize things on disk. And that is just part of the story. Resources are loaded and discarded on demand, which means memory fragmentation. I have put some extra information on resources to help with compaction, but still need to implement the system. If a resource is moved, some pointers need to be adjusted here and there. I have some ideas, but problems will appear for sure.

May have to consider handling multiple floppies loading?
In my Atari Falcon painting program I had a memory manager that moved things around: Instead of asking memory to the system you provided a small memory location that the memory manager would modify itself when repacking memory. That allowed for some fancy stuff like shrinking or expanding memory buffers

Without challenges that would not be as interesting!

[Godzil]

Ho ok silly me, I was thinking that you wrote your own parser/language

I should have spotted that it was XA output

The interesting things in the adventure games has never been to find out the one clickable pixel hidden in some complicated pixel art structure, but more in finding how to use things to progress.

I agree and disagree, on some SCUMM game it is part of some puzzle to figure that this or this is clickable, if you just need to use "tab" to go through all active element it remove that soft of puzzle.

BIG SPOILER HERE FOR THOSE WHO HAVEN'T PLAYER INDIANA JONES and THE FATE OF ATLANTIS, so it you want to play it, DO NOT READ!

Takes IJAFOA, in the Aztek (or Inca can't remember) temple, you have to figure that the decoration on the left part is something that can be clicked and be removed in some way to open the tomb.
(see this pictures for thoses who need a reminder: http://i.ytimg.com/vi/xAWddsXJzEY/hqdefault.jpg )

if we where about to cycle through all active element it would make such puzzle really borring

END OF SPOILER

May have to consider handling multiple floppies loading?

I would recomment this approach too, even if some data are duplicated alongs all the floppy it's not a big deal.

There are two approach for the multi floppy, the FinalFantasy VII way or the Baldur's gate way.

The first is floppy are use each after the other with the story, you start on floppy one and end on floppy X.
The baldur's gate way is a floppy with a bunch of area and all it's variations, it can be even just one area if it's really a big one.

Both approach are valid and will really depends on the fluidity of the game, if following the story does not need to swap too often the floppy it would be nicer to swap floppy everytime you change from a room A to B.

For the second approach would be to have some duplicated rooms between floppy

Here is a just a simple and stupid example, imagine that you have 3 rooms, A, B and C, you can only travel from A to B and B to C (and of course C to B and B to A) but you can't fit all of them in one floppy.

What you can do is to have A and B on floppy one and B and C on floppy two, the idea is if the player goes from A to B and B to A you don't need to swap floppies, and the same from B and C, if will only be needed if you do A->B->C or C->B->A.

That's my 2 cents

[Chema]

Interesting comments indeed.

About the mouse thing, I agree with Dbug and also hate the games where finding that hidden object is key for solving a puzzle. But I guess that is the designer's fault. I toyed with the idea of having some intelligent cursor placement as an option, but then again Gozil has a point: you don't want people run through rooms just pressing a key repeatedly to find out all the possibilities. Besides it could be cumbersome if there are too many objects around or when trying to select an action.

The scene in the Scumm bar in MI where you can interact with the so many people, including a dog, is an example. And also the automatic highlighting (showing the object in the sentence as soon as the cursor is over it) is a good improvement over Maniac Mansion's "What is" action.

Anyway something to consider.

About the multiple disk thing, what the original scumm does is keeping a list with the resources including in which disk they are stored. In fact most resources are further organized into the rooms. Basically it is up to you to decide where to put data and the system will ask for the needed disk when necessary. I guess this makes possible to use the system you like.

And I think I should also support it. My concern is more about how to organize things. Some resources are big, as they include graphics, but others may be small. And there are quite a lot of them, so wasting the spare room of a sector to store 20 bytes might be a problem. The same goes for efficient loading.

I wonder if it would be a good idea to keep several related resources in a sector and load all of them when asking for one. But it depends on the available memory at a particular moment...

And even more. Some resources are "local", which means they are bound to a specific room. You can have several script number 210 in different rooms, and I am not sure how to do this. I think they did this because they ended up with more than 256 scripts and didn't want to number them with two bytes. Besides there are some unnumbered resources (such as scripts that execute when you enter a room).

I can change that, if needed, but need to think about a simple system but make sure I won't exhaust the number of a type of resource in the middle of the game development!

Anything else? Ah yes, about the PC tools. It would be fantastic but sink into PC programming with something so complex and even considering it could be used by other people... Argh!

[Godzil]

It would be a problem at some point, but don't think too early about storage optimisation, it could be done when things are ready and you will need to pack a real game.

Don't overthink about space problem, a multi floppy solution will at some point waste space so don't be too eager to regain a 400 Byte until really needed.

I would not say the same thing for memory management of course, but for floppy it's not that important unless you are really missing the 400bytes

[Dbug]

I guess a good way of having a clearer idea would be to just try to code naively one of the typical scenes of the game, and see how much memory/storage that requires. Then only extrapolate to what that would represent for the full game

[Chema]

I guess you're right guys. I'll leave that for later. Anyway I have still a lot of work ahead so it can wait...

As soon as I have more time, I'll dig into making the inventory basics.

Thanks.

[Symoon]

About the mouse thing, I agree with Dbug and also hate the games where finding that hidden object is key for solving a puzzle. But I guess that is the designer's fault. I toyed with the idea of having some intelligent cursor placement as an option, but then again Gozil has a point: you don't want people run through rooms just pressing a key repeatedly to find out all the possibilities. Besides it could be cumbersome if there are too many objects around or when trying to select an action.

Another option is the way the Atari ST handled moving the mouse cursor with the keyboard, IIRC:
- CTRL + arrow keys = "fast" moving (jumping something like 10 pixels at time)
- CTRL + SHIFT + arrow keys = slow moving, pixel by pixel

That was an easy way to go fast to the part of the screen you wanted to go, and then just press an additional key to put the cursor precisely where it had to be.

The problem with the "real" Oric is that moving the arrow keys requires two hands (being placed on the two sides of the space bar), so having another key to press would be painful.
But you can go like Tyrann for instance, that uses IJKL keys to simulate the arrow keys, so only one hand is required. So you'd go:
- use IJKL keys to move the cursor fast
- use SHIFT + IJKL keys to move it slowly

Just an idea.

[Dbug]

I would suggest using WASD then (instead of IJKL), at least people who have been playing on PCs for the last two decades would feel at home

[peacer]

In the first versions of sierra games (kings quest, leisure suit of larry etc) user has to write write all the commands as a sentence everytime ( like ASK WINE FROM BARTENDER ). It was so hard to guess what kind of sentence to choose, and writing commands everytime was really diffucult. That's why, instead of typing commands, in games like Maniac mansion, there were many actions on the screen that user has to choose (like GO TO, TAKE, DROP, USE WITH, OPEN, CLOSE, TALK TO etc.. )

I have played DOS version of these games from my first PC without mouse too. It was so annoying to use keyboard and choose appropriate action.

Later, they made remakes of these classical games. But this time, instead of any actions to choose, computer decides which action to do when mouse is over an object. (i.e. if mouse is on the door and you click on it, it opens the door. If you click on an opened box, box is closed. If you click on a person you talk to that person etc).

This type of game playing did not lower the joy but increase the playability for sure.

I think its easier to program this kind of user interface too, other than expecting user to select from various commands.