Xelda

I've decided to take on the Zelda tribute game and take over the Xelda title (because it's a great title name). Working with the MK2 Mojon twins game engine. Here's what I've done so far.

https://youtu.be/POGi6ODznyo

This is still a long ways off and game puzzles are being thought of, however not yet programmed. All I have now is a walk around engine. The map is still in the beginning phases. I am also still experimenting with how many screens I can put into the game, I'm thinking somewhere around 200+ screens. Of course, this will be for 128k only.

This is an ambitious project so at some point I might need some assistance in programming and puzzle creation as well as map creation.

This will be an open source project with the source code posted. Of course, when the project is done, I will upload the game somewhere. If I get to the point where I am defeated on creation, I will still post the source code so someone else can take up the mantle.

Andy Dansby
«1

Comments

  • I've thought "wouldn't it be cool if there was a Zelda game on the Speccy" many times, so this is definitely something I'm interested in.

    Link's Awakening is, possibly, my favourite game of all time :)
    My only Speccy game (so far): a simple snake clone
  • That's exactly what I thought. There not much too much game wise that the Gameboy could do that couldn't be tried on the Speccy. At some point after I build the basics I might need help with development as this will be a rather large project (at least if the game is going to be any good). I also have bouncing in the back of my head some sort of password system generated on the major variables that will provide for level advancement. I'm thinking of something that will capture level/screen/x,y/objects_acquired/flags that might show as a series of hex numbers.
  • looks excellent so far
    Professional Mel-the-Bell Simulator................"So realistic, I found myself reaching for the Kleenex King-Size!" - Richard Darling
  • edited March 2017
    tree.gif

    That's the viewpoint you need to do your trees.
    Post edited by redballoon on
  • redballoon wrote: »
    tree.gif

    That's the viewpoint you need to do your trees.

    Thanks redballoon, I was hoping to see your name pop up on this thread. All of the graphics I am using are either ripped, modified etc, but not all are solid, so I am just using pseudo in-place graphics for now until I get all of the major game screens working.
  • I think it would be cool if you could mimic the way 'local' maps scroll in Gameboy / SNES Zelda. So you have a small region that scrolls, but it only goes so far, then you flip-screen when you reach the edge. Even if it was just in the vertical direction, you could have more interesting dungeons.

    You wouldn't need a huge ever-scrolling map with a wrap-around scenery buffer; just use a buffer 50-100% bigger than the screen, and draw all the sprites in the local area on it, then copy a window of it to the display.

    You could do pixel or 2-pixel scrolling vertically, but you'd need to carefully plan around colour transitions with generous use of solid black bits.
    Joefish
    - IONIAN-GAMES.com -
  • A clone of Zelda is an ambitious project so you shouldn't really try to do too much and keep to stuff that is appropriate for your skill and amount of free time to work on this project.

    Actually first Zelda game is quite primitive. If someone forgot, it's how it looks:
    http://www.mobygames.com/game/legend-of-zelda/screenshots

    I could mention quite a lot of Spectrum games that look better ;)

    The question is - are you going to make a clone of this game or some later part of the series?

    The current graphics are quite simple (and quite cute in their childish naive style ;) ) but I guess that they are placeholders and are going to change.

    So good luck with your work, show us your progress and ask here if you have any questions!

  • As has been mentioned, I think the best thing to aim for is something like Link's Awakening. The first game lacked any sort of joined-up sense of progress or story, and the second (side-on view) was pretty awful all round.

    What's particularly interesting about Link's Awakening is that instead of having multi-levelled dungeons, it had 'secret passages' that bridged two points on the dungeon map (or even the main map) that played as side-on platform sections. And it occurs to me that you can easily combine platform and maze sections with the same game engine simply by designating certain empty tiles as 'gravity tiles', which give you a downward acceleration.

    Whenever you're over one of these tiles, you 'fall' down the screen. So on a platform section, you fill all the empty spaces with 'gravity tiles' to make you fall down (unless there's a solid block in the way). Ladders are then simply ordinary 'walk on' tiles where no gravity is applied. And weapons, bombs, etc. still work on the locality.

    The fiddly bit is if you do have a jump move, like when you've obtained the 'Roc's Feather', how to implement it in the map view world to make sure you do atart and end the jump at the same level. I suppose on the Spectrum that would best be implemented as an automatic hop-over-a-hole in map mode, akin to the 'hover boots' in N64 Zelda.
    Joefish
    - IONIAN-GAMES.com -
  • andydansby wrote: »
    I also have bouncing in the back of my head some sort of password system generated on the major variables that will provide for level advancement. I'm thinking of something that will capture level/screen/x,y/objects_acquired/flags that might show as a series of hex numbers.

    I've had a look in my "big folder of projects that I might eventually finish" and found the password system I developed for a speccy game blatantly ripped off from heavily inspired by, Link's Awakening. It uses base 32 encoding, rather than hex, feel free to use, abuse, adapt or ignore. It encodes the entire save state in 64 bits, so the password only needs to be 13 characters long.
    Password uses characters: 23456789ABCDEFGHJKLMNPQRSTUVWXYZ
    
    Note avoidance of 0,1,I,O which are the most 
    commonly misinterpreted letters - especially in handwriting.
    
    |<--- CHARACTER 1-->|<--- CHARACTER 2---->|<--- CHARACTER 3-->|<---
    +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
    | 63| 62| 61| 60| 59| 58| 57| 56| | 55| 54| 53| 52| 51| 50| 49| 48|
    +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
    |<---Screen number------------->| |<----Hearts--->|<-----Coins-----
    
    --CHARACTER 4-->|<--- CHARACTER 5 --->|<--- CHARACTER 6 ->|<-------
    +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
    | 47| 46| 45| 44| 43| 42| 41| 40| | 39| 38| 37| 36| 35| 34| 33| 32|
    +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
    -----Coins------------->|<--------------Item flags-----------------
    
    CHARACTER 7>|<--- CHARACTER 8 ->| |<-- CHARACTER 9 -->|<--CHAR 10--
    +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
    | 31| 30| 29| 28| 27| 26| 25| 24| | 23| 22| 21| 20| 19| 18| 17| 16|
    +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
    -----Item flags-------->|<-----------Arrows------>|<-----Bombs-----
    
    ------->|<-- CHARACTER 11-->|<-- CHARACTER 12 --> |<-- CHARACTER 13---->|
    +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ +---+
    | 15| 14| 13| 12| 11| 10| 9 | 8 | | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |   |
    +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ +---+
    --Bombs>|<---Dungeon--->|<--- Keys held ----->|<---start pos ---->| parity
    
    Dungeon is the number of the last dungeon completed.
    
    Start pos is the entry point to the current screen, determined as follows:
    
    +--+--+--+--+--+--+--+--+--+--+--+
    |  |00|01|02|03|04|05|07|08|09|  |
    +--+--+--+--+--+--+--+--+--+--+--+
    |1E|  |  |  |  |  |  |  |  |  |0A|
    +--+--+--+--+--+--+--+--+--+--+--+
    |1D|  |  |  |  |  |  |  |  |  |0B|
    +--+--+--+--+--+--+--+--+--+--+--+
    |1C|  |  |  |  |1F|  |  |  |  |0C|
    +--+--+--+--+--+--+--+--+--+--+--+
    |1B|  |  |  |  |  |  |  |  |  |0D|
    +--+--+--+--+--+--+--+--+--+--+--+
    |1A|  |  |  |  |  |  |  |  |  |0E|
    +--+--+--+--+--+--+--+--+--+--+--+
    |19|  |  |  |  |  |  |  |  |  |0F|
    +--+--+--+--+--+--+--+--+--+--+--+
    |  |18|17|16|15|14|13|12|11|10|  |
    +--+--+--+--+--+--+--+--+--+--+--+
    
    
    




    Comp.Sys.Sinclair Crap Games Competition 2017
    Everyone has a crap game inside them, let yours out!
  • edited March 2017
    You could also design the game to minimise the amount of data you need to save.

    You could cut back the number of possible restart points drastically (e.g. a central home, each dungeon entrance). Just restart with basic health. Make ammunition easy to come by so it's not a disaster if you restart with middling amounts. Or convert it back into cash or generic 'ammo credit' before you save. You could even reset the dungeons. These sorts of things you might do if you die and choose 'Continue' to keep playing. (I was properly caught out when I first played Mana, because when it says 'Game Over' it really means it!)

    In Link's Awakening, there's a general object exchange hand-off that goes on for ages, but you're only carrying one item at any one time. And you can infer your weapons/equipment from the number of your next dungeon. By foisting certain choices upon you, you can infer the health boosts too. You could add an extra bit for when you get the dungeon key, or just have a 'story progress' number that increments both when you get the key and again when you complete the dungeon.

    It's nice to collect coins, but even that's not necessarily vital to the game. If you need it to play mini-games, then you could just drop game tokens at random around the environment and you have to find them anew if you restart. And often money is just used as another artificial barrier - e.g you need 300 coins for a gadget but you can only carry 200 until you get a 'bigger wallet'; they might as well just give you the thing itself at that point.
    Post edited by joefish on
    Joefish
    - IONIAN-GAMES.com -
  • I've been playing around with a links awakening remake for the spectrum on and off. Mainly to see if it could be done. Not as far as long as your project though. Looks cool.
  • I did have an idea for a randomly-generated Zelda type game. Instead of saving, you just make each adventure short enough to play in one sitting.

    You use a seedable random maze generator for the dungeons that leaves a branching path and various dead-ends. Then you put treasures and keys in the dead-ends, and a corresponding door along the main path for each key placed down a side-branch. If there are too many side-branches you just seal them off.

    The weapons used in the game get picked randomly from a list, and for each there's a standard 'obstruction' both on the world map and in each dungeon that you can only get past with that weapon (e.g. a gap to jump/float/grapple/shoot across, rock to lift/blow up/levitate, plant to freeze/burn/grow into a ladder). In a dungeon, the weapon is equivalent to a key and the obstruction is placed where you'd find the equivalent door.

    The fun part would be randomly generated character names and plot clichés assembled on-the-fly into some sort of order for a story to develop.

    The problem is coming up with puzzles to solve in the dungeons. Ones with random elements would be tough to implement and vary in difficulty; converesely you'd need a massive collection of pre-defined one-room puzzles if it's not going to spoil the random nature of the game with obvious repetitions.
    Joefish
    - IONIAN-GAMES.com -
  • So many great suggestions, thank you.

    @joefish as for local map scrolling, I'm not sure if the MK2 engine does that, it's more of a screen flipper. Perhaps if it were the creator of the MK2 engine (Mojon Twins), he might be able to do that, however, they are far and above more advanced in understanding the engine than I will ever be.

    I started trying to do this with the Churro engine, but it is lacking some features, so I am on at least my 3rd iteration of the 'walk around'. As for the multi level dungeon, that is very possible and I am planning on doing such a thing, not to different than what I do to pop between levels.

    There's still alot to do, I don't even have all the screens and levels linked together yet, I got 4 levels, but plan on at least 12-15 levels, each of 20 screens. It's should be packed with the number of screen, but special features such as inventory is on the back burner for now until I can see how much I can pack in the 128k. To how how far away I am, I just a few days ago was able to page in a different level (level 3) from RAM 4. About 6-7 more levels should fit in that page.

    This will be open source once I am able to see how many levels I can squeeze in, so everyone can have a chance to improve the game, I'm thinking of a community effort, I'm just starting the ball rolling and getting interest.

    @GReW & joefish Thanks for the idea on saving info for games, the idea is that when the user presses a key, a code will be displayed on screen that the user writes down, If they want to go back, they press another key, type in the code and they are back This is however way long in the future.

    @hikoki. I have been on the Mojon Twins forum and have read that, I'm staying away from the sword, I havent gotten it to work well with the Top down (moggy) view, works great with side view, but on top down, the sword will tend to face the wrong way just as you make a turn. So for this game, the character will use a crossbow, however you can only fire one shot at a time.


    @dave18, you will be able to modify the source (it's in C, using Z88DK and SP1). I will release the source soon and it can be a community effort.

    Thanks for the support. Now off for a nap.

    Andy
  • Just added 2 new blank levels in RAM bank 4, it seems to jump nicely between RAM banks.


  • andydansby wrote: »
    @hikoki. I have been on the Mojon Twins forum and have read that, I'm staying away from the sword, I havent gotten it to work well with the Top down (moggy) view, works great with side view, but on top down, the sword will tend to face the wrong way just as you make a turn. So for this game, the character will use a crossbow, however you can only fire one shot at a time.
    "It's dangerous to go alone! Take... er... never mind."

    This whole project sounds crazily ambitious and far beyond any programming I could imagine... but best of luck with it because it sounds utterly wonderful. As for the amount of memory and storage space you'll need, the Famicom Disk System original in 1986 fit into 128 kilobytes... and you could always have it as a +3 or TR-DOS game and load dungeon maps in from the disc as they're required.

    Fight for the Front and freedom! Move out! Oh, wait... wrong game.
  • @andydansby have you thought of opening a thread for the game on Mojonia's forum? the gurus seem to be programming more for the NES lately but they may give you a hand in there too
  • edited March 2017
    @The Mighty Dopethrone well hopefully, the game engine that I am using will make this task easier than you are thinking, but also my plans on making this a community project will allow the generous members of WOS to help me along the way, plus with open source, it will be easier to write sequels. Not a lick of this game would be done by me if there wasn't that engine.

    @hikoki I am a member of that forum, and sadly it's very quiet there. I even have a PM sent to nathan and I've not yet received a response, so he must be slammed with projects, they are a busy group. There is a question I have on the forums about some errors I've encountered, i.e. WARP_TO_LEVEL and FIRE_ZONE, but again it's quiet on the boards. btw, I've found a workaround to the WARP_TO_LEVEL and not to FIRE_ZONE, so the transition between levels is not as seamless as I had hoped.

    Everything is subject to change, nothing written in stone, I don't even own chisels.

    Andy
    Post edited by andydansby on
  • Had a look around to see if Link's Awakening had been disassembled, and found this:
    https://kemenaran.winosx.com/posts/category-disassembling-links-awakening/

    Interesting read. Of course, it would be more useful if he (or she?) went into detail about the in-game physics, but worth keeping an eye on this blog.
    My only Speccy game (so far): a simple snake clone
  • chriswyatt wrote: »
    Had a look around to see if Link's Awakening had been disassembled, and found this:
    https://kemenaran.winosx.com/posts/category-disassembling-links-awakening/

    Interesting read. Of course, it would be more useful if he (or she?) went into detail about the in-game physics, but worth keeping an eye on this blog.

    Good find, a very interesting read. I am at this point still trying to get the basics down on the game. I am at this point not even concentrating on plot, puzzles, graphics, etc. I don't have sprites for the most of the enemies yet, all still far away. This is nothing more than a test to see how many screens/ levels I can fit in the game, with nothing more in the script than warping and level setup, I am at 1100 lines. So I probably will dial down any special features, aiming at a larger game with few effects rather than a smaller game with more special effects.

    My plan so far in the game is to have 200-250 screens (memory dependent), to have 4 dungeons & 4 bosses). I would want to have mazes and logical puzzles as well a simple inventory system. Finally, I want to have some password system to allow a long game to be restored by typing in a code (much like what GReW suggested).

    If the puzzles and script get too large, then screens will have to be dialed back.

    Most importantly, I want this to be a community effort, so at some point once I have some basics down, I will place the code on my google drive and allow others to work on the game, so not only will development be faster, but I can have some other ideas on how this should progress. We also have to bear in mind, how much the game engine can do and what is really feasible within the limitations of 128k.

    Thanks
    Andy Dansby

  • I had a basic walk around engine with a few screens but it was quickly apparent that memory restraints would require some data packing - each 20 x 16 screen was taking 640 bytes including attr data. The next job was to build in RLE packing and decoding but I never got around to it. Might have to dig out the source and have another play.

    @Andy - How are you packing the map data?

    Dave
  • @dave18

    I'm doing this all in the Mohon Twins MK2 framework. First I'm making this a 128K game only so I can bank in multiple levels. I can fit about 5-6 levels per bank except for bank 3 which also holds title screen, the border of the game screen and finish screen.

    Each level contains 20 screens and you can move back and forth between each level to make it appear as if it were 1 large level but it's not. The level data is created in the Mappy program with 16 tiles, however, there is a 48 tile set to choose from. You have to set in the script for placement of additional tiles past the first 16. This allows for a more compressed level than using the 48 tile set. One drawback to this is that you cannot use animated tiles, but not a horrible sacrifice.

    Once the map and additional tiles are built, when you compile the game, I am using the apack utility to compress the level to about a 3rd of the original size. This program is just another part of the MK2 framework. Using this I have 200 15x10 screens including attributes.

    Building the script to jump back and forth between levels is rather easy, but I had to create a spreadsheet to keep track of it all as I'll end up with about 75-100 connections to track of. I probably should have one for decorations, as they can be monotonous.

    My concerns about memory are not yet over as I still need to create puzzles, dialogue, a sort of inventory system, some sound fx and perhaps music.

    Depending on all of that, I still might have to scale down, which is why I am not even thinking about various effects etc.

    All in all, it's pretty large for a single person, which is why I will eventually release the source so others can help with coding and perhaps get other ideas.

    If you would like to help with the coding Dave I'll be happy to include you just give me a few weeks or so to finish the groundwork for the level data.

    Here is a link for how I am creating levels for the game in the MK2 framework.

    https://onedrive.live.com/?authkey=%21AMIn8anePH1HkRg&cid=A3FA0A9EDEE237D7&id=A3FA0A9EDEE237D7%219965&parId=A3FA0A9EDEE237D7%219964&o=OneUp

    Andy Dansby

  • Thanks I'll check it out. I was always planning on making mine a game for modern storage devices (eg DivIDE). The idea being the map is split into regions of between 20 and 32 squares (depending on compression) with all location specific tiles, sprites, music and text. Each region wpuld be loaded dynamically as needed into a bank as needed (if not already in a bank) with some intelligent code to ditch the furthest away region. Load times would be negligible and allow for the complete game. Bit ambitious but it should be possible. May never be finished but I like to work on it every now and again just for fun.
  • Impressive so far.
    My only Speccy game (so far): a simple snake clone
  • This is just a test. Haven't even started design of levels. The graphics are mostly in place graphics, over 260 screens in this test. I've been playing with scripting and message at this time. Still a long ways to go,

    https://1drv.ms/u/s!Atc34t6eCvqj0nAUDser8lI8CzRd

    enjoy.

    Andy Dansby
  • edited March 2017
    For dungeons you might want to try to implement a way to re-use simple corridor and corner rooms, or have some sort of generic 'empty room' where you can just programatically add N/S/E/W exits. Perhaps a common north/south corridor with a big locked door right in the middle could be used every time you need a choke point.

    And for common big empty rooms, have something else to add various versions of 'kill all the monsters in this room to open the doors', and perhaps dispense treasure, maybe even a key.
    Post edited by joefish on
    Joefish
    - IONIAN-GAMES.com -
  • Right now it's all pretty much blank. 9 main map levels, 4 dungeon levels, 1 inside houses level. I have the first few quests already in mind, but for now I'm working on some basics for scripting where most of the game lies. The script length right now is pretty large and I hope I can find an easier way to manage it and break it up a bit.
    Andy
  • edited April 2017
    Interesting - can you post up a small example of a script and explain a bit more what the problem is?
    Post edited by KrazyKattapilla on
  • The problem is more of a length issue. When I jump from one area to another, I find myself scrolling from the top of the script to some point in the middle and then again to the bottom. It's 2K lines, so find the right spot to move to can be irritating and lengthy for the simplest function. I am doing this in notepad++, so I have the ability to have tabs for each level.

    I've since decided to break up the script into manageable chunks and then recombine them when I compile.

    Each chunk is a level, so I think going forward I will have an easier time finding the right spot.

    Andy Dansby

    btw, writing the script is not difficult as the scripting logic is straightforward if you want to see how the script looks
    #gatekeeper
    ENTERING SCREEN 3
    IF TRUE
    	THEN
    		SET_FIRE_ZONE 97, 129, 127, 159
    	END
    END
    #gatekeeper
    PRESS_FIRE AT SCREEN 3
    
    #YOU CANNOT PASS THE GATE
    	IF $TALK_GATEKEEPER = 0
    	IF PLAYER_TOUCHES 10, 5
    	THEN
    		EXTERN 44
    		REDRAW
    	END
    	
    	#you can now pass the gate
    	IF $TALK_GATEKEEPER = 1
    	IF PLAYER_TOUCHES 10, 5
    	THEN
    		EXTERN 51
    		REDRAW
    		SET $SWAMP_GATE = 1
    	END
    	IF PLAYER_IN_X 97, 127
        IF PLAYER_IN_Y 129, 159
        THEN
    		SET $WARPED_TO_HERE = 82
    		WARP_TO_LEVEL 0, 1, 10, 1, 1
        END
    END
    

    which goes on for about 2000 lines or so which is why I need an easier way to manage it.
  • Andy - thanks.

    So the problem is more of you managing the script whilst writing it rather than processing it within your code?

    IIRC Notepad ++ lets you collapse sections of code which could be useful.



    KK

Sign In or Register to comment.