Quest Quest: A Graphic Adventure (new download available!)

[kalan_vod]

This is looking really good, I like how it highlights the object . And the speed seems fast too , hehe its asm duh.

[threefingeredguy]

It looks really good. I can't wait to play.

[CompWiz]

Wow, that looks great! I hope it progresses quickly! I like the way the sprites, items, and other tiles were drawn. They look very nice. I can't wait to play.

I had an idea. If you make an external level editor, other people could work on levels, and you can concentrate on the game engine. That way, when you finish the game engine, there will be plenty of levels ready to use it right away, and you don't have to worry about creating levels. Maybe even a contest for the best designed level? Just a thought.

[L4E_WakaMol-King]

Hmm, interesting.

Thanks for your suggestion... I'll take that into consideration. But it would require a significant bit of restructuring in the Z80 code, and then I'd have to program a level editor. The level editor would have to be on the computer... would probably have to make it in Java or VB. There's really no feasable way to do a level editor on the calc, since there is so much text involved, plus a compiler of sorts is needed to convert the user level into usable Z80 code.

Depending on how popular the game is, I might do this at a later date. But for now I need to focus on just getting the original done. Thanks for the input.

[necro]

<off topic> why is everyone using modded zelda sprites for anything 16X16?

[L4E_WakaMol-King]

IMO, they are the best, followed by Pokemon. The main character is actually a hybrid of Ash and Link, with a little original modification. 16 x 16 sprites are deff the easiest thing to squish down into 12 x 12, which is what I need for this game.

[L4E_WakaMol-King]

I've spent the last few days on the dialogue engine, which, as I feared, would be the hardest part yet. I basically had to create my own scripting language and interpriter. Here's the functions that the dialogue engine will support:

1. Statements: Person you are talking to makes a statement.
2. Reply Menus: You choose what your character will say from a menu. The items in the menu are linked to other scripts... usually statements from other characters (their replies to what you say). The items in the menu can be dynamic... meaning that they can change as the dialogue progresses, or they can show up/not show up depending on certain conditions (such as you having a certain item in your inventory).
3. Getting / Losing Items: You can receive or give away items during a dialogue with another character.
4. Change Sprites or Map: Your sprite or the sprites of other characters can change during a dialogue. This is for characters that do actions as you talk to them. The map can also change during a dialogue.

As you can guess, this has been a pain in the rear end to program. I've finished #1 and am currently putting the finishing touches on #2. #3 and 4 should be fairly easy compared to #2. (Just the code for displaying and cycling through the menus is several pages long.)

I hope to have an animated screenshot of a dialogue for you some time soon... maybe by next weekend. It probably won't demonstrate all the features, but it will be enough to get the idea across.

Current size of game program + data file: 6.5 k and rising fast.

[kalan_vod]

It sounds well planed out, mabee I should make plans before I code and just lose intrest...[/ramble]

[NanoWar]

As I can see you have 16 pixels of free space on the (right-left) borders. Are you going to put something in?
Like the name of the game or a status bar or just some cool '&@%!#' ?

Do you have money in this game? Or HP (it isnt a RPG right?)?

Or you can let your charakter walk 8 pixels as one step ( then you dont have a border, but you must rewrite the map routine...! ).

Edit: Oops, are you really using 12x12 sprites?

Edit: And I dont like the inverse highlighting thing, because the font dodges the border of the text box when highlighted...

Edit: I love editing

[L4E_WakaMol-King]

As I can see you have 16 pixels of free space on the (right-left) borders. Are you going to put something in?
Like the name of the game or a status bar or just some cool '&@%!#' ?

Do you have money in this game? Or HP (it isnt a RPG right?)?

I don't know yet. There's no real stats to be displayed, and I think the title of the game might be a bit obtrusive. This isn't an RPG, but a graphic adventure. There's no money to speak of and no HP or MP. Also, it's only 12 pixils of room on the sides I believe. That's enough room for one more sprite, but then the main character wouldn't be centered on the screen.

Edit: Oops, are you really using 12x12 sprites?

Yep

Edit: And I dont like the inverse highlighting thing, because the font dodges the border of the text box when highlighted...

I'm not sure I like that either, but I think it's better than just leaving the thing you are looking at in plain text, since eventually you will be able to replace that word with other words... things from your inventory for example. What do the rest of you think about this?

[threefingeredguy]

I like the sound of it.

[NanoWar]

Then make the text box one pixel bigger and Im okay with that!

[L4E_WakaMol-King]

Already considered that option, but right now it fits perfectly into the bottom row of sprites. Don't want to go into an in-depth description of why this is important, but trust me, increasing its size by one pixil would create a number of problems.

Ok, need an opinion here - Would the extra space on the sides look better black instead of white?

[tr1p1ea]

Wow this is looking just plain cool! Its a good idea to use an external data file becauase this project will probably use a lot of text. I dont see why you would need 'vector-tables within vector-tables' just to read some text data from the archive though?

Compile the DATA file with the -s option (TASM) ... and make sure you .org $0000. Then you take the .SYM file and modify it so it reads _label = $XXXX. You then include this file in your main project. As soon as the main program loads it should try to locate the data file. Once found save the page number and data offset. Your text routine should simply add the _label equate and the data offset together and use something like _loadCindPaged or even _FlashToRAM to read the text data.

Im not sure if i lost anyone there ... also if you currently have it working i say just leave it that way .

EDIT - I just realised that you are using this program as an easter egg, maybe its best that you forget what i wrote (or do _label = XXXX - $9D95 or something).

*hides*

[L4E_WakaMol-King]

Well, I'm not very savvy with the idiosyncrasies of asm, so I'm not exactly sure what you said.

Here's a basic description of my data file. It has some executable code at the very top of it that will be the Easter egg, but other than that, there is no actual code in the file. It's just all data... text strings and scripts to run on the engine I described a few posts earlier. Basically, I've made all the labels in the file relative labels, meaning that instead of being actual memory addresses, they are distances from the start of the file.

The data file holds a lot of stuff, so that's why there are vector tables within vector tables. For example, the first vector table is the 'main menu' if you will. It holds the relative address of the LOOK AT scripts, the TALK TO scripts, the USE scripts, etc. So the game uses that table to figure out where to go based on what the player is doing. Once the game links to one of those places... say the TALK TO scripts for example... there's another vector table of the addresses of each specific script. Each entry in the table goes like this:

.db [map number],

Code: Select all

.dw relative memory address of script to execute

A concrete example:

.db 5,103
.dw $00F3

So, when the game gets to this table, it looks through the table to find a match.  If you are on the fifth map and trying to talk to the 103rd sprite, it will jump to the location (start of data file + $00F3).

But that's not all!  There's more!  (I feel like a used car salesman.)  Dialogue between characters is dynamic... meaning that it's not just a bunch of scrolling text.  They say stuff, then you get a menu of options of things to say... then they say different stuff depending on what you said.  There might be repeats and loops and your choices might change depending on certain conditions.  Plus, you might gain or lose items while talking to people, or the map might change.  That's why the scripts can't just be lines of text.  They have to be [i]yet a third and much more complex[/i] type of vector table that will hold all the options you can say, all the options they can say, and all the 'intelligence' to modify and use each one.  It makes my brain hurt just thinking about it.  Perhaps I should have picked a slightly easier project for my first asm program.  Oh well, too late now.  :oops:

Hope that makes sense.  I don't know if it's the most efficient way to do this, but I've come so far using this method that unless someone find a way that is much more efficient, I will probably stick with it.