[T-Bone]

I've been working on this one for several years but I just don't see myself finishing it at all. Here's a short demo of it.

Attached File(s)

•  Zelda The Inquest Demo.zip (816.23K)
  Number of downloads: 135

[Old-Sckool]

The level design reminds me of Twilight Princess for some reason...

[Lachesis]

Several years and that's all you had done? O_O

[T-Bone]

I did towns, ponds, deserts, fortresses, caves and forests as well as a mountain region. The game took many different turns graphically and also how it functions has changed a lot, when you move from board to board. So I've kept those parts out of the demo for now since they are drastically different from any of the interior stuff you see in this example. Its more of an example/test then a demo.

I originally had a version of the game i started in about 1999 when i first got MZX; that had many places to go and lots of secrets and enemies, items, dialog and bosses. But it used primarily built-in objects like bombs, gems, healths and ammo (for arrows) which took away from the traditional feel of any Zelda game. I still have some of the components from that one, I have recovered. Could upload that one as well to show a bit of the evolution.

If I get around to it, i might put together the true demo. Just have a lot of work on my plate as it is. But if there is issues in whats in the example that people may have problems with or how the engine is working or anything really; I'll be glad to note it down and possibly make the changes when I get the time. Though I'm currently treating this as a dump right now.

One thing i never touched on with this game, even its previous version, was a menu system. Which is pretty much the key element in the original Zelda games.

Due to time management, I'm finding it hard to do things completely on my own now with so many projects.I might have to consider putting a group together to help me out with such projects like this one.

This post has been edited by T-Bone: 11 August 2010 - 04:33 PM

[Old-Sckool]

An item select screen wouldn't be that hard to make. I could probably write a simplified Link's Awakening style item select engine in less than two hours.

[T-Bone]

Would it be the V-Layer with sprites or by overlays?

The menu slides up or down i cant recall, over the playable screen. For simplification i think overlays might be the easiest approach, stored in maybe MZM.

One thing i do like about the old styled Zelda menus is that items appear in a certain place on the menu screen as you obtain them. This is easier to do then having each item shuffle based on which one you have obtained last. Just a simply plot in to a specific location for a given item on the menu. Be cool though if you wanted to do some work with that. Enter for menu is what i had originally intended. (key_code = 28?)

If a menu is constructed I could do some tests with a lantern, which you can use to attack enemies near by or light up torches in caves. The boomerang is a bit tough for me. I'd need assistance on that one for sure with the behaviors. I'm not very good with the math in MegaZeux. It would definitely be a sprite much like the sword. I could work on the hammer no problem. That would be just a simply N,S,E,W animation with a given label in the direction to any robots.

The enemies right now need some fixing up. If i get fee time I'll work on that.... but when do i ever get free time anymore? >_<
The enemies can sometimes walk in the way of doorways... they also dont lock when your in an interaction with a person or chest or item that may freeze the player. This results in you being attacked while your frozen.

Also noticed the heart metre doesn't work all that properly either. Lot of little things to work on just to make a working demo.

[Old-Sckool]

I made a menu engine cuz it was fun. Here's how to use it...

-Files-

Other than the .mzx, there are five files (LoadOnceMenu.txt, Menu.txt, Items.mzm, Menu.mzm, and MenuMask.mzm). As you'd expect LoadOnceMenu loads all of the variables, the 3 sprites I use to draw the Menu (numbers 249-251), while Menu is the engine itself. Items.mzm contains the graphical data for the cursor and the items and the cursor. Menu.mzm should be obvious, while MenuMask.mzm was intended to be used to prevent the menu sprite from grabbing the color from the layer below it.

- Variables -

My personal preference with variables is that I tend to avoid using local variables (since locals can't be debugged with f11, and aren't descriptive). To avoid naming conflicts, I group similar variables so that they sort of represent the data contained by an "object".

menu - This group of variables manages the Sprite (#250) that will display Menu.mzm. The sprite itself is static. To move the menu, send the Menu robot to #MoveMenu to reposition the menu on the screen, or #HideMenu to hide it completely. These variables also manages the Sprite (#249) that displays MenuMask.mzm beneath the menu.

inv - The group of variables that manage the items that can be wielded (current inventory), and how they are formatted in the menu. invX/Y manages the position that the inventory appears, which is relative to the upper right corner of the Menu. InvW/H manages the number of columns/rows of items that you can have.

$inv - a 1-dimensional array that contains the items you currently have stowed away. The length of this array is InvW*InvH, and each element defaults to "None". To add an item to the inventory, set $addItem to the item name you defined with $items, and send the robot "Menu" to #additem.

item - the group of variables that determine the size of each item icon. I've set that to 3x3, since the cursor I drew is 3x3, and is also the reason why Items.mzm has the cursor graphic in it.

$item(s) - the group of variables that determine how Items.mzm should be formatted, and are used to determine which icon to use for which item. The $items variable is used to give the item icons a "name". See LoadOnceMenu.txt to get an idea of what i mean.

$ERROR - used for debugging purposes. Helps to find my screw-ups.

- Engine Functions -

: "OpenMenu" - Locks the player and opens the menu. Directionals move the cursor, Z equips an item to $weapA, X equips an item to $weapB, enter leaves the menu. Right now, you have to use another robot to open up the menu, but not to close it... I probably should fix that.

: "#MoveMenu" - Moves the menu to MenuX, MenuY

: "#HideMenu" - Removes the menu from the screen.

: "#AddItem" - Adds the item stored in $additem to the next open spot in the inventory, or sets $ERROR if it can't

- Future Improvements -

If you make up a menu layout for me, I could also make it possible for each item to show off a unique description, like in the Gameboy games.

There are also a few small things I can fix, like making it so that you can actually see what item you've equipped.

Attached File(s)

•  ZeldaEngine.zip (5.5K)
  Number of downloads: 52

This post has been edited by Old-Sckool: 14 August 2010 - 05:08 AM

[T-Bone]

Can't take a look at it right now since I have quite a lot of work to do from now until the 29th. But it all sounds really promising. So this set up would cause all items in the inventory to cascade to the up-most-left by the sounds of it?

[T-Bone]

Noticed a lot of problems that are associated with the player's health. I'll be switching the counter for health from "Health" to "hp" since certain actions override what I want to happen when your health is depleted.