Gateway to Legend is an open-source Puzzle-RPG. The main focus of the game will obviously be solving puzzles to get experience, as any Puzzle-RPG would have it, but the mechanics that make this game unique is that most puzzle mechanics will be based off doors or gates! Switches and door pairs allow you to gain access to rooms, teleporters provide gates between two places on the map, and more! It also supports the development and easy integration of user-generated content, as well; you can make puzzle map-packs for this project! I've done quite a bit of work on this engine so far, and I'd like to show it off. Here's what I have so far:


In this video, I show off the work I've done with enemies and pathfinding, music, and sound effects! Bosses, the toolchain, and abilities are also shown off!

There are 3 enemy types: Fast but low damage and HP moving straight to you, slow but higher damage and HP, taking a slower, more methodical path, and a third, which totally ignores collision.

There's also a map-pack wizard that helps user-generated content, as far as the programs go. I have my Github repository over here, and I would very much appreciate any suggestions from the community!

Other Stuff:
* Join my Discord! I post more frequent updates there.
* Take a look at my website I wrote!
* See my GameJolt Page!
This is a really interesting idea. Are you thinking turn-based combat like SoU? Or real time like Zelda?

I wonder would it be possible to make this cross-platform compatible with the TI-84+CE? Depending on what kind of format you're intending to use for storing maps, events, etc. it might be possible to create interpreters for different platforms (much like Lucasfilm Games did back in the day with SCUMM).
JamesV wrote:
This is a really interesting idea. Are you thinking turn-based combat like SoU? Or real time like Zelda?

I wonder would it be possible to make this cross-platform compatible with the TI-84+CE? Depending on what kind of format you're intending to use for storing maps, events, etc. it might be possible to create interpreters for different platforms (much like Lucasfilm Games did back in the day with SCUMM).

I'm planning to go more for a real-time approach like a Zelda game. I think to make it compatible you'd have to probably only use one or two AppVars per map pack instead of the 4-ish used per map-pack on PC. Other than that, it's probably doable. The event- and tilemaps are stored in the same line, as hex data, so realistically all you'd need to do is read two hex digits for events, two for tilemaps, and then you have the first tile done. Repeat that 20x15 times (for each tile) and you'd have that data loaded in. I honestly think the most challenging aspect would be reading AppVars to determine which are dedicated map files and which aren't, but I'd have to ask MateoConLechuga about that, since he had lots of success with Oiram and its map creator.
Searching the appvars for map files would require some assembly (or could be possible with C, I'm not sure), and the appvars could have a header string that the game would identify. If you decide you want 84+CE compatibility and you need any assembly help, I can do my best to be of assistance.

Compression would be useful on the calculator as well to reduce the map data. I've used Huffman in various projects over the years, so again, if that's something that you're interested in, I can help. I've also got some Huffman compression & decompression routines written in C# that I'm sure could be ported to C.
The nice thing about the C toolchain is that it has dedicated routines for searching for appvars and other variable types with a particular starting header. It also offers optimal compression and decompression routines for ease of use. If your computer-side algorithm is written in C; it can be dropped in to work on the calculator with little to no effort Smile

Anyway this looks like quite the game; with a neat concept! It would be nice to see running on the CE Smile
MateoConLechuga wrote:
The nice thing about the C toolchain is that it has dedicated routines for searching for appvars and other variable types with a particular starting header. It also offers optimal compression and decompression routines for ease of use. If your computer-side algorithm is written in C; it can be dropped in to work on the calculator with little to no effort Smile

Anyway this looks like quite the game; with a neat concept! It would be nice to see running on the CE Smile
Well that does make things considerably less complicated if you decide to include a CE version Smile
JamesV wrote:
Searching the appvars for map files would require some assembly (or could be possible with C, I'm not sure), and the appvars could have a header string that the game would identify. If you decide you want 84+CE compatibility and you need any assembly help, I can do my best to be of assistance.

Compression would be useful on the calculator as well to reduce the map data. I've used Huffman in various projects over the years, so again, if that's something that you're interested in, I can help. I've also got some Huffman compression & decompression routines written in C# that I'm sure could be ported to C.

I think that compression is a good idea either way. I think it's important to reduce file size for something like map data, as well as it being a nice programming and logical exercise I have yet to delve into.

MateoConLechuga wrote:
The nice thing about the C toolchain is that it has dedicated routines for searching for appvars and other variable types with a particular starting header. It also offers optimal compression and decompression routines for ease of use. If your computer-side algorithm is written in C; it can be dropped in to work on the calculator with little to no effort Smile

Anyway this looks like quite the game; with a neat concept! It would be nice to see running on the CE Smile

Awesome! That makes things a lot easier to port over. I'm not very familiar with the CE, seeing as I don't have a CE, and thus no ROM (since I dump my own ROMs). I'd probably need quite a bit of help testing and making sure compatibility remains between computer and calculator versions. If I'm interested in porting it or letting someone port it with me, I'd definitely take the opportunity to release on multiple systems!

I'm not sure if I mentioned, but this has already been implemented: I allow creators, in their map-packs, to use any data files they want; maps and saves, which I don't recommend since reusing saves will most likely make the game think the player has already beaten the game, and reusing maps defeats the purpose of a MAP-pack. I also allow creators to use any tileset they want! This means that any map-pack can use their own 48x48 tileset! For the main game, I intend to use 8x8 tiles upscaled x6, but anyone could use 16x16 tiles, for example, or just 48x48. I intend to explore this possibility myself when I make some side-content, but that's an aspect of the design I'm really looking forward to.

Also, screenshot coming soon! I have some shiny new visual progress in the works, and I just have to refine it.


Here's my new progress! You can see that all the "event" tiles, or puzzle mechanics, are displayed onscreen. I also implemented button and door behaviors, with framework to do the same thing for each tile. I also did a lot of work on the map toolchain, making it so that each program can be compiled with the same header file(s), meaning no extra bloat in the build directory, among other changes like always displaying event tiles there too.


I have some new progress to display! This screenshot, I made some decently big progress on the engine! I added the ability to write scripts for your maps. Scripts are versatile lines of data that define behavior of a certain map. In this case, I showed a script that warps the player to any other map, in any other coordinates. This is a "use portal" script, which, when stepping on a warp gate tile with defined behavior, shows a fading animation like I displayed, then puts the player in a new map. The warp gate script will be used to very good effect in the main map-pack, and map-makers will obviously be allowed to use this script to its fullest as well! You may ask how the warp gate is a mechanic worth showing, and I concede, it's not exactly a mechanic. However, the freedom that the warp gate script, and scripts in general, provide is enough to get me excited. When I start developing the main map-pack for real, you will be convinced on how to effectively use such a device.

Other script behavior has already been defined, such as a dialogue script, which displays the specified line of text upon triggering the event. I haven't written it yet, but there will be some sort of script editor. Whether that's included in the map editor, its own seperate tool, or whatever, it will exist.
Nice progress 123outerme! The scripts sound a lot like mods, which I like the idea of. The sprites and other stuff also look nice! Keep up the great work Smile

Also, how will map-packs be implemented? Will they use scripts as well?
Battlesquid wrote:
Nice progress 123outerme! The scripts sound a lot like mods, which I like the idea of. The sprites and other stuff also look nice! Keep up the great work Smile

Also, how will map-packs be implemented? Will they use scripts as well?

Thanks! The scripts are a little bit like mods, but instead of allowing custom code to be run, they just select where an when a predefined snippet of code is run. Thanks! I'm really fond of the warp gate sprite but I might make it a bit bigger.

Map-packs will be implemented through 5 files: The map-pack "header" file, containing the in-game name, where to find all the other files, where to place the player upon starting a new game, and which tileset tiles map to which eventmap tiles, all of which will be easily configurable with the map-pack creation wizard. The map file is the text file where all map data is stored. The tileset .png is obviously the png spritesheet. The save file is obviously where map-pack specific save data will be stored. Finally, the scripts file holds all the script data for the individual map-pack, so to answer your question, yes, all map-packs will be able to use scripts as well.

To go more in-depth into how scripts will work, you will have a script creator/editor that allows you to configure what script type it is, what exactly it does, where the trigger area is, and more. This data will be outputted into a file and through the console, and then it's up to you to paste it into your script file. The beauty of my implementation is that you don't have to organize scripts by their corresponding map; all scripts in the file are loaded upon starting the game, and relevant ones will be applied without much slowdown, if any.
Good work, 123outerme Smile The warp animation is cool looking. I'm looking forward to seeing what flexibility the events allow.

Out of curiosity, what kind of triggers are you looking to implement? Do events just trigger from the player walking into the particular area of the map? Will there be events that are triggered by certain enemies being killed, or a certain number of enemies being killed, etc.?
JamesV wrote:
Good work, 123outerme Smile The warp animation is cool looking. I'm looking forward to seeing what flexibility the events allow.

Out of curiosity, what kind of triggers are you looking to implement? Do events just trigger from the player walking into the particular area of the map? Will there be events that are triggered by certain enemies being killed, or a certain number of enemies being killed, etc.?

Thanks! I'm glad I was able to implement the animation and the script system as well as it is.

So far, I have triggers that go off based on proximity to a coordinate in a map (i.e. you specify which map it's active for, where on that map it is, and the width/height of the box it should be applied in), as well as that + what tile you stepped on, which is how warp tiles are currently activated. I could theoretically use any trigger, such as button presses, enemies dying, boss stuff, etc., but for the most part, the groundwork is based off of coordinates. I like the idea of a script activating by a number of enemies killed, or something like that, like a score-based trigger. I'll have to give it some more thought!


Here's a look at a little bit of work I did on this today! I added an HP display, removed FPS counter (you can bring it back by pressing a certain key, although I haven't decided which key yet), and added the functionality to spikes! Spikes reduce 1/4 of a heart in damage per contact, and you are also thrown back in the direction you moved. This is done by increasing your velocity so that you are automatically moved. This velocity system I put in place will also be used for enemies and maybe some more puzzle mechanics.


Here's my new update! I finally bit the bullet and implemented enemies in their entirety, after months of practically radio silence on the matter. Yes, if you're wondering, POTY 2017 did motivate me to get working again, among other things. Enemies can collide with you, knocking you back and dealing damage, collide with the sword, dying (although in the future I will have some enemies have more HP, taking damage and getting knocked back as well), and not shown here and not implemented quite yet, collide with the environment. Every enemy will have some sort of special attributes.

For right now, the implementation of the special attributes is: the bird does not collide with the environment and does minimal damage, while flying straight at the player. The stone ent attacks like a rook; it tries to line itself up with the player's left-right, then attacks, does good damage, and moves rather slowly. The slime enemy has yet to be implemented fully.

I think I may change this around, especially as map-packs will be using different tiles for the enemies. I would like to make each enemy's behavior individual, yet generic enough so that a multitude of enemy appearances can fit the same type.
I love this! Keep going!


I have successfully implemented my own home-grown (yet not really unique) pathfinding algorithm! Enemies 1 and 3, or the bird and the stone giant. The 2nd enemy, the specter, can walk through collision. They (mostly) take the shortest path to the player from their starting position, and do it pretty fast too! With 2 enemies utilizing the routine, and a 3rd one moving without it, I get an uncapped FPS of about 450, which I find very impressive.The algorithm I used was just a flash-fill that takes data from the eventmap and plots a path through without colliding with walls, although I may extend that to not collide with other things such as portals, spikes, etc.

I'm really proud of it, as in 8 hours I went from not knowing anything about pathfinding to implementing my own into my game. I'm glad I could get it to work and the euphoria after realizing it worked was gold.


Here I've implemented sound effects! No music yet, that's coming real soon, though! I bitcrushed royalty-free sound effects and did other wacky things to give them the feel I wanted. I have sound effects for doors, gateways, sword swings, selecting menu options, walking, with more coming soon! Finally, no more silent-treatment from my PC games. Let me know which sound effects you like and dislike, and I'll do my best to make them better.
So right now, I'm reworking the main tilesheet to be 48x48, instead of 8x8 (upscaled x6). I figured I might as well show off everything the engine can do, including the resolution it can play at. I haven't made every tile yet, but I have done a few. I updated the spike tile in the upper left, the heart icon, the portal sprite (although I may not be done with that one), the sword, and the grass. I still have most of the tileset to do, but I figured I'd show off this progress. Here's some of my work so far:




I intend to keep this cartoony style for the most part. It's not only easier for someone who isn't really an artist, not only the way my 8x8 tiles looked, but I think it fits pretty well. I would like to hear any criticisms or suggestions you have to offer! Any praise is welcome, as well Wink

As for work on the engine, nothing crazy has been added or removed, yet. I have big plans for features, such as fully-customizable boss behaviors, implementing new events and puzzle mechanics, adding dialogue, and more. The maps featured right now in the Main Adventure map pack are mostly test maps. The work on the real Main Adventure will come in time, mostly once I'm finished a lot of the big features.

RPG mechanics will most likely be present. I'm thinking pretty much just money and Exp as the two point systems in place, but probably nothing more, if just that. I don't exactly know if I even want Exp in the first place, and I'll have to see how it will play out. The money will for certain be in, and will most likely be used to buy techniques, items, and other goodies I haven't yet decided on.


I finally finished my work on my tileset after a weekend of working on it, so here it is! I took what little art talent I have and upscaled the graphics. I previously used 8x8-sized tiles for the "main" map-pack, but figured I could do better. After all, if the game can display up to 48x48 tiles, why limit myself? I agree that some things may need work, and I will continue to look at and improve the tileset. Another point of potential ugliness is the maps I'm using right now; the maps will soon be remade and will look better than they do now!

Here's a list of things that are coming up in the somewhat short-term, in no particular order:

* Redoing the menu palette
* Script editor; "scripts" are lines of data that dictate where and when certain things like warping, etc. happen, so a easy-to-use editor for myself and other map-pack creators is coming!
* More sound effects
* Music
* Currency and the currency store, as well as potentially Exp
* Actual options to change the FPS, volume, etc.
* Bosses and customizable boss behavior
* Local saves holding more data so that some sort of permanent state is kept between rooms
* More types of events such as dialogue, scene scripting (!), etc.
* More engine work
* Probably redoing some of my 48x48 tiles


As well, here's my goals for the long term, in the same unordered fashion:

* Release a beta version with a complete toolchain to give everyone a head-start on making maps
* Finish the main map-pack
* Release the finished version alongside a few more map-packs (secret projects!)
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 3
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement