New Game in progress: Castle Rex

[ral-clan]

I really love the look of the hi-res "room" images you are creating! The MacVenture move interface makes a lot of sense, too.

[Mike]

Blast, you found it! That blog was supposed to be a joke, but I've been documenting some progress [...] there are a couple embarrassing entries, which, if you'll excuse me, I will clean up quickly.

Aren't these what blogs are about? Not that I've thought, there were any embarrassing entries at all ... otherwise I'd have PM'd you about the blog first.

The last image is the sprite editor. It supports monochrome with transparency output at resolutions up to 40x48.

Funny! It looks as if you're using the line display routine of MG BROWSE with "user defined characters".

Well, I haven't progressed much since my last blog entry, but here's a screenshot:

Nice to see the game is taking shape. How many game screens are supposed to be in there in the end?

[Wilson]

ral-clan, thanks!

Aren't these what blogs are about? Not that I've thought, there were any embarrassing entries at all ...

Right you are! Maybe embarrassing was the wrong word. I just felt they revealed my ignorance on topics that most Denial members are very familiar with.

Funny! It looks as if you're using the line display routine of MG BROWSE with "user defined characters".

No, but I wish I would have thought of that! I can't remember how I did it, but perhaps I'll revisit that idea later.

How many game screens are supposed to be in there in the end?

I'm not quite sure yet. I'd like to have more than 35. I believe Shadowgate had 46, and it seemed like a good length. I'll have to experiment with compression to see how small I can get the files. With so many images, the one disk-side limit starts to get a little claustrophobic.

[Mike]

I can't remember how I did it, but perhaps I'll revisit that idea later.

It just was my first guess. Of course, once it works you really won't need to change the program. But maybe that idea comes handy for other display cases.

With so many images, the one disk-side limit starts to get a little claustrophobic.

What limit? You could always go for a 1581. And the sd2iec handles *.d81 files without problems.

[saehn]

I can't remember how I did it, but perhaps I'll revisit that idea later.

It just was my first guess. Of course, once it works you really won't need to change the program. But maybe that idea comes handy for other display cases.

With so many images, the one disk-side limit starts to get a little claustrophobic.

What limit? You could always go for a 1581. And the sd2iec handles *.d81 files without problems.

True, but disk-swapping/flipping would get a wider audience.

[Mike]

What limit? You could always go for a 1581. And the sd2iec handles *.d81 files without problems.

True, but disk-swapping/flipping would get a wider audience.

Those concerned, who happen not to have the necessary hardware at hand, can always use VICE instead.

[tlr]

With so many images, the one disk-side limit starts to get a little claustrophobic.

What limit? You could always go for a 1581. And the sd2iec handles *.d81 files without problems.

You can could also use more than 35 tracks on your disk-side.

[saehn]

What limit? You could always go for a 1581. And the sd2iec handles *.d81 files without problems.

True, but disk-swapping/flipping would get a wider audience.

Those concerned, who happen not to have the necessary hardware at hand, can always use VICE instead.

Or he could use a simple system that accommodates any drive type: attempt to load the file and if it is not found, prompt for the necessary disk/side.

[orion70]

Or he could use a simple system that accommodates any drive type: attempt to load the file and if it is not found, prompt for the necessary disk/side.

Great! I vote for this.

[Wilson]

All good suggestions. The more I think about it, the more I am realizing how big of a stretch one .d64 disk side (even 40 sectors) will be. Even if I put the engine on the other side. I will probably try to add drive independent loading as saehn suggested since it doesn't seem like too much work. Realistically, the game will be much more enjoyable on a .d81 in VICE with true-drive emulation disabled.

[Pedro Lambrini]

Just wondering how this project is going. Is it still going?

[Wilson]

Thanks for the interest, Pedro!

Yes, it's still going. I've been taking a break for a while, and unfortunately this break is going to continue for some time. The reason for the break is, as it was last time, to work on other Vic-20 "experiments".
There is relatively little work to be done before I have a fully functional engine, but beyond that the editor must be written to support all the new features. And then there's always room to improve.

The area that I've done most work since my last update is in scripting.
When the player enters the room (after the room is loaded) the BASIC "script" that is loaded with that room is run. This is used for initialization things.
An example that comes to mind is a lightning flash that occurs when the player enters a certain room. When initialization is done, a SYS is executed that gives
control to the engine's handling routines. If one does not desire to pass control to the engine's handling routines ever, he/she does not have to.

Now, the engine's handling routines include things like opening a door upon the "OPEN" action, unlocking a door upon the "USE" action paired with the proper active item.
Every action except USE is handled completely by the engine. USE is a special action. When it is not used with a key on a locked object, it is used to trigger a bytecode "script" to handle common actions.
If one wishes to implement behavior not provided by any of the bytecode actions, he/she can take advantage of the action "pass control to BASIC line $xxxx". As you might expect, BASIC takes control at the line given until the SYS to return control to the engine occurs.

This is all very confusing to say in words. It should help to see the structure for the noun. This is what all of the engine's handling is based off of. I apologize for the messed up formatting.

Code: Select all

	enable		.byte		; if 0, the object is not displayed/handled
	action		.byte		; bits: 0:object can be looked at, 1:object usable, 2:object takeable, 3:object openable, 
				    	        ;  4:object closable 5:object "speakable" (whatever that means) 6:object can be moved to, 7:object leavable
	action2		.byte		; bits: 0:object hittable, 1-7 undefined
	name		.byte		; string ID of name
	sprite		.byte		; sprite ID
	openState 	.byte		; if 0= open, $FE= closed, else locked until the item of this ID is used. (if not openable this is error string)
	dest		.byte		; destination of "MOVE" if passable, else ID of preposition for error handling
	lookAt		.byte		; ID of string displayed upon action "LOOK"
	item		.byte		; the item ID of the object or error string
	weight		.byte		; item weight. if > player strength, item cannot be taken.
	tKey		.byte		; the item that must be USE'd on the object to trigger tActions (if 0, no item must be used)
	tNumActions	.byte		; the number of actions that are performed upon action "USE" with the item tKey (if 0, there is no trigger)
	tActions    	.byte		; a variable number of actions to be performed by the engine (in the engine's binary format)

I've made some visual changes as well.
Here's a new screenshot. It should be pretty self explanatory. That little bug by the inventory's scroll down button is from the image.


Like I said, it might be a bit before I get back to working on this, but I'm happy to answer any questions or take suggestions.

[Pedro Lambrini]

That seems like a fair bit of work done - though it still seems like you've got a lot to do!

The game looks pretty different from the initial screenshots. Is this the style you intend to go with or is it just another step in the evolution?

[Mike]

Any news?

[OBSysteme]

Holy cow!!! I had never noticed this thread before... this is awesome, I hope you see it through!