Legend Of Zelda Series - 01 - Introduction

 

 I am currently Re-Building the original Zelda from scratch using Java. My goal is to keep the gameplay, mechanics, and limitations as accurate as possible while programming in Java programming language and with Object Oriented style. Once I have done this, I then want to remake the sequel using my created JavaZelda engine to make the sequel more like the original game.

One thing I want to make sure I get right is the boomerang. I also think that this will be one of the hardest things to program. I suspect the Boomerang functionality was accidental and replicating it will be hard. The thing about the boomerang is that it can be thrown in all four cardinal directions, can also be sent out in all four diagonals, and can be sent out in all four cardinals and immediately be turned into another direction. This boomerang throw is what I believe to be the accidental programming but is unique and sometimes useful in game.

The NES Screen size limitations were 256*240. The tiles seem to have been done in a 16*16 configuration giving us a 16*15 tiled screen. The top part of the screen is taken up by the mini map and Link’s hearts and current equipped items. That bit seems to be about 4.5. Which means each that the play screen is about 16*10.5. I have also been reading that the tiles are done in an 8*8 configuration, which would make more sense as that would make the play screen 32*21 and the status screen 32*9. Whole numbers like this make more sense, but we will see how it plays out. 

 

I do not have to worry about the colour limitations because I am using existing sprites and assets and will not be making anything custom at this point. If I do reach my goals and remake the sequel then I will have to consider the colour limitations of the NES at that point.

The gameplay of the Zelda seems to be screen based. The game loads only the current screen and as link moves from one screen to another it loads the new screen, transitions to the new screen, and unloads the previous screen. They did this to limit the amount of memory used at any given time. This also explains why there is little variation in mob spawning. I am thinking to achieve this I will use a 2d array for the world map, and every cell will have a value assigned to it. That value will reference a screen composition, which will be another 2d array that tells the program how to render the new screen. This 2d array will hold values for each entity that needs to be loaded into the screen. I think that this can also apply to the dungeons.

The world map is 16*8. This equates to 128 screens to build. Plus, all the secret screens from the world map, which I counted as 69. Seems like an odd amount though and I will have to recount that. And I do not even want to think about the dungeon screens yet. Each of those 128 screens will have 16*10.5 or 168 cells that need to have scene values assigned to them. This means that 128*168 = 21504 cells. Most of the values can be 0 for nothing, but this is going to be a lot of work to map everything out. …. A map / tile editor might be a good idea.

While I have been thinking about the how to build the overworld, I have also been thinking about the Entity tree. I am going to program this in Object Oriented style, and I will be using inheritance to create an entity tree. This is the first time I have planned an entity tree, and I am very unsure if I am doing it well or not.

The entity tree so far:

 

Next Steps for future posts:

- Start building out the UMLs and Java classes for the entities

- Start populating the screen arrays

- Start trying to get the screen manager coded and the first 1^st screen coded and displayed with Link loaded into it.