Hey all, a few months ago I started on an Axe project that was inspired the Mystery Dungeon series as well as by this tutorial series:

The goal was to make a relatively simple graphical roguelike for the TI-83+/84+ calculators as well create general engine with code that can be reused for similar projects in the future. I have been working on it on and off, but this month I plan to get some real progress done. I'm hoping this thread will serve a few purposes:
First, keep me motivated/focused. I'm not sure if I'll complete this by the end of the month, but I would like to make a fair bit of progress and hopefully get it in a playable state.
Second, get some feedback. I posted a few screenshots in the Discord here and there but not everyone on the forums uses Discord. I'm hoping to have a bit more visibility and interest here.
Lastly, I'm hoping that I can use this thread like a sort of dev blog, detailing my progress and my thought process throughout. I also plan to make it completely open source once it is complete. If I somehow lose all motivation I plan on sharing the source regardless of the game's state.

So with that being said, let's start with what's been done so far (with complementary eye candy, every screenshot is in 6MHz mode):

This is the very first iteration of the tilemapper, complete with tile collisions. The code came from yunhua's tilemapper tutorial over on Omnimaga. It was pretty simple afterwards to make the game constantly loop over the player sprite animations Mystery Dungeon style. Once that was complete I went to work trying to implement a very rudimentary mob system. First step was to simply display a mob to the screen... which kinda worked.

I fixed the jittery-ness of the scrolling but I would learn later that I did not completely remove all of the bugs with displaying mobs. Next up was mob collision, which was basically making it so you can't just walk right through mobs on the map.

Initially this was pretty difficult for me to implement, but thanks to E37 over on Omnimaga I got it working. However, there was a problem that I knew I was going to have to deal with: speed. In this iteration, the tilemap was redrawn every frame. Which also meant that the more mobs I added, the slower the game would get simply by drawing them. This was without factoring in any other possible systems like AI. So my next thought was "how can I make this faster?" So I looked high and low through the forums, both Omnimaga and Cemetech to see if I could make the tilemapper faster. I found the answer in Runer112's YAAM and GRAYLIB programs. I spent the better part of a week reading through and trying to understand the YAAM source and the GRAYPKMN source to see how he was getting the speed he was. Eventually I was able to put together a nice and fast unaligned tilemapper that was not redrawn every frame. The code is pretty much entirely his, I just made a few adjustments/adaptations. The result?

With the new tilemapper up and running, adding mobs would no longer be as detrimental to the performance, so mission accomplished there.

I then spent about 2 days trying to fix the aforementioned issue with displaying mobs, which looked something like this:

There was supposed to be one mob added to the map in this screenshot, but it was displaying at least three times over. The fix was a pretty simple line of code that performed double duty: it prevented the mobs from repeating out of bounds, and it also made it so that mobs are no longer drawn if they are a certain range away from the player. This is pretty important for performance as well, as it meant that the game was no longer drawing mobs off-screen. From there it was simple to re-implement mob collision.

Thanks to Hayleia over on the Codewalrus server, I was also able to write a custom 4x4 font routine:

So what's next? Right now, I am designing the general gameplay. Currently my idea is to make the game around 20 or so procedurally generated floors with various slime types, each with their own unique behavior. Each floor will be 48x48 tiles in size. In terms of player progress, since the scope of the game is relatively small, I plan to have the player earn gold every time they kill a slime, and for there to be a shop (think Kecleon shop in Mystery Dungeon) for the player to buy items and weapons on every floor. This is still very much subject to change, and I have a few other ideas floating around in my head. Since the game won't have an XP or level up system, I plan to have the player increase their max health through purchasing an item from the dungeon shops. I am also unsure if I am going to include a hunger mechanic but I'm currently leaning towards yes at the moment. There will be an item throwing mechanic and I'm also thinking of adding a simple charge-based magic system. If you're familiar with Shiren the Wanderer, think staves. I think the combination of these mechanics will make for a simple yet interesting rougelike experience.
There's a lot of work to be done but the next thing I'm thinking of working on is either floor generation or making it so you can attack mobs. Floor generation sounds a little more fun so I might go with that.
What do you guys think so far? Any questions, feedback or suggestions? Thanks for reading!
Fascinating progress so far! I see you have a lot of features planned, but what I am curious about the most is how the primary gameplay loop will turn out — how fun it will be, what fights will be like, etc. I look forward to the progress Smile
I love the progression screenshots and I'll always have a soft spot for the monochrome calcs.

This looks great so far, especially the speed and animation.
tr1p1ea wrote:
I love the progression screenshots and I'll always have a soft spot for the monochrome calcs.

This looks great so far, especially the speed and animation.

I second this, plus I also have a soft spot for top-down games, whether they're RPG, ARPG, shoot-em-up, etc. I look forward to seeing this develop more!
This looks very promising! I like the main character movement especially and scrolling seems smooth. Smile
In more normal terms, This looks really good! I like the greyscale, especially for an axe program, and the smooth scrolling blows me away. Don't sprites get clipped if they go offscreen? That blows me away!
Thanks for the kind words everyone. Once again, the credit for the tilemapper really should go to Runer. The optimized code and the concept behind how it all works is all his. Basically, I'm using 2 buffers. The back buffer, L3, for the tilemap and L6 for the player and mobs. The tilemap works by drawing the rows or columns of tiles depending on the direction you're moving in and then shifts them in with a for loop. Then I use RecallPic to copy the back buffer to the front buffer and sprites are drawn with overwrite logic.
As for drawing the mobs? I'm doing this with several different functions. First I have a function that adds a mob to an array. For now it just takes their X and Y position on the map and uses that to calculate their "real" position in the map data. It looks like this:
Lbl AddMob
   If L<18

This was written thanks to Deep Thought's array tutorial. It was a big help.
Next comes the actual drawing. Here is the code responsible for drawing the game and the mobs:

Lbl DrawGame
Lbl DrawMob
      If ([r1]>>~64) and ([r1]<<64) and ([r2]>>~48) and ([r2]<<48)

Essentially what I'm doing here is drawing the mobs relative to the player's pixel position on the screen. This only works because the player sprite never actually moves. But what about the scrolling? To keep this short, I'm going to just go over movement in one direction.

If getKey(1)
   8 CheckTile()
Lbl ScrollDown
   Vertical -ʳ
   -12 :ClearRow()
   35 :DrawRow()
Lbl MoveDown
   !If Solid
      If NoMob(48)

The scrolling code is all Runer. I just changed the names of the functions for readability. The code for movement, however is mine. As you may have noticed, I was using MX and MY in the display code for the mobs. I'm simply incrementing by 8 or decrementing by 8 in the for loop to shift their pixel positions to correspond to the movement of the tilemap, then resetting their values back to 0 at the end. The result is some nice smooth scrolling and sprites that don't clip when they shift partially offscreen. I'm definitely going to have to change this a bit when I make them able to move, and probably refactor the movement code to account for it, but I already have an idea as to how I'm going to do it.
Hey everyone! It's time for a quick little update post!

I've been busy with work and other life stuff these last 2 weeks, but I did manage to sneak in some time to work on the dungeon generation. So far, I've written out in pseudocode notes a pretty complete algorithm for generating all the rooms that are going to be on a floor. In HCWP yesterday, I got started on translating my notes into code and completed the first part which is simply generating a room. Right now I generate a single room that lies within the bounds of the map and is the appropriate size. The most important part was making sure that the starting upper left corner of the room was a valid location. After that I was able to design a method checking the width and height so that if the upper right and lower left corners of the room lie outside an acceptable range to simply reselect a new size.
The screenshot isn't particularly spectacular, but it shows the room generation working:

Here I show the the bounds of the map then show that the randomly generated room does in fact lie within those bounds.
I do run into 2 bugs with the program so far. The first bug being that when ever I hit [Clear] to exit the program, my calculator crashes and my RAM clears. The second bug is the bit of corrupted tiles in the upper left corner at the beginning of the screen shot. The tilemapping and movement code is all the same from before, and I didn't encounter any issues when exiting when I didn't generate the room but used the hardcoded map. In regards to the second bug, I'm not sure what is even causing it. The code for creating a blank map is as follows:


The code simply creating a room is this:


When I first tested this code by manually creating a room, the corrupted tile issue did not occur. This only happened when the program generates a room as opposed to me hard coding one. Perhaps there's an issue with how I create the appvar? That could be the source of both of my bugs. Not sure. If anyone who knows Axe has any idea what's causing them, let me know.
With that being said, I'm going to continue working on floor generation. Next up is translating the notes I have in determining whether subsequent rooms are too close to or overlap with already existing rooms. Wish me luck and see you hopefully next week!
Assuming RoomStart is correct, I think your code is fine. One thing I've noticed is sometimes after a ram clear, the OS doesn't return the correct pointer to a new file. One thing you can try is sending over a file you manually created, then use your program to overwrite the contents.

I never really looked into the issue, but it was obnoxious.
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 1
» 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