I’ve been working on 2 major things that look small but are actually pretty big:

• Currency buttons: I’ve had to do some major revamps to several parts of the GUI system, but now I have buttons that show the currency. I am now using these for the upgrades, buy towers, and the new tower shop with the shards. I am now allowing for icon elements to be passed into the Button class. This allows for custom positioning, and thus this new way of buttons. Then I had to change the way that elements refreshed in the GUI managers. It took a while to figure out, but now they will be red if there isn’t enough currency.
• Main menu background: Art is incredibly time-consuming for me, and I keep scrapping designs but I think this one is the one and the one I’ll stick with for the finished thing.

I’ve started work on a tower shop. I spent several hours drawing the background, but I think it came out looking really good. It only took so much time, which is why I’m making the log now. I also used a template human model for the merchant. I am going to show the different upgrades on the menu. I haven’t added the buy functionality yet, but that will probably be pretty easy. I got some chill guitar music from opengameart.

A little bit faster progress now.

• Tower Shop: I have started work on a tower shop. I want it to be from the POV of the player looking into a medieval stall. As of right now, I’m still working on drawing it, and also it’s still hidden and non-functional. I edited all the towers to have a requirement of another tower, so as to make it a progression later on,
• Data Saving: I am going to start implementing a save system. For this, I just put some values into a data class and then implemented a way to save it to and load it from JSON.
• Molten Lands: There is a new map now, the molten lands. I also made a lava slime which is a bit stronger than the other enemies except for the bosses. It took a while to draw the sandy tiles for it, but I feel as though I’ve gotten much better at drawing than before.
• Logging: I added logging. This probably should’ve been added earlier, but this will help tremendously to fix any bugs in the code. For now, I am logging pretty much everything that doesn’t happen every frame, like when an enemy dies or the user clicks on a button.

Progress has been (very) slow but there’s some more new content:

• Crabs & Bat: I added crab enemies. There is a normal crab that is like a slime and then an armored crab (not shown in video) that is bigger and meant to be a boss. There is also a bat enemy.
• Pause Menu: Theere is a pause menu now. It allows the user to retry the map or go back to the main menu. I am finally making use of the other features of the scene manager. It’s a different scene but it’s rendered on top of the main game scene. I had to modify the scene manager to draw each scene on top of the last one in the stack. Otherwise, this is just the same usage of my GUI system.
• Rebalances: I did some rebalancing of the game. Towers generally cost different amounts of coins now and do different amounts of damage. I’ll probably have to do it again by the end of the project but this will do for now.
• Music: I am in the process of adding music. I am getting them from https://opengameart.org and crediting all publishers. I have a system where it will queue music files from a playlist and play those in sequence. They are pretty long files, but just in case.
  I’m probably forgetting some stuff (last time I touched this was like a week ago), but those are the major things.

I am very glad stardance got extended! This definitely eases the pressure A LOT . Bit of a shorter devlog so as to not accidentally pass the 10h deadline. Here are the updates:

• Venom shooter: The venom shooter is a plant that shoots venom. It will poison the enemy. I did this through another effect. The recording doesn’t show it’s full potential, because I kind of force pushed to the repository and now I lost the change, but I have it on another computer. Essentuially, the damage over time is going to increase with the update instead of staying static and linked to the effect.
• More tiles!: I added the stone path tiles. They still need a little bit of work, as some areas don’t fully connect. The nice thing about working with stone sprites is that the textures connect pretty well regardless, but it’s still something I need to fix.
• New Map: I added a new map, Frontier. This one is just a somewhat harder version of Ground Zero, mostly to test out if the map selector and the new tiles actually worked. The map selector just had to be tweaked to refresh the UI when a new button is clicked, which is only one line, but otherwise everything went smoothly.
• Ghost: I added a new enemy, the Ghost. The ghost looks like a tortured soul, and at the moment he hasn’t received proper stats, so he’s just a clone of the slime. I want to make it somewhere in between the slime and fast slime. It uses a lot more frames than the other enemies to make it somewhat smooth.
  Ok chat I think we got this in the bag im tryna get that bambu a1 3d printer frfr i think i can get it now that the deadline has been increased tysm stardance devs!!!!

Ok, so a lot of progress, though it has been slow because the school year has genuinely driven a train through my productivity:

• Upgrades: This is the most recent thing, but basically I added upgrades. This is handled by using a list of values instead of single values when creating a new subclass of a Tower class. I track an upgrade index and increase it to change the index and some other stuff. I made some icons and added it to the tower selected menu. I will show the coins cost of the upgrade next, because I forgot to do that. I also made new sprites for the upgrades, and a complete resprite for the cannon, which badly needed it. I also remade the tower base, which looks much better now.
• Speed setting: I added a speed setting. This was a matter of tracking a delta time multiplier, and then multiplying it with everything that uses delta time. Remember that delta time is the amount of time between frames. It lets the developer do things like move an enemy at a movement speed independent of the frame rate, because the movement is split between the delta time.
• Frostspire: I added a new Frostspire tower. This is a tower that shoots icicles at enemies and makes them slower. To do the slower part, I made an effect system that gets appended to an array in the enemy. Effects have an overlay color, and will have several attributes that are applied to the enemy if it has them. As of right now, there is just a movement speed multiplier. I want to add a final venom tower that damages enemies over time, and that should be pretty easy.
• Tank slime: I added a tank slime, which is supposed to be the final boss of the Ground Zero map. I’m not sure if I have the inspiration to make more enemies other than slimes, or the drawing skills. Essentially it’s just a much bigger slime (takes up the whole width of the path) and green, and slower, and has a lot of health. I have to take the time to balance everything though, because 2 of the basic crossbows can kill it as of right now.

I did this devlog mostly because I wanted to get a screenshot of (hopefully) six seven hours , but there has been some progress, even if it’s slow because now I have other things to do .

• Map Selector: I implemented a map selector, which will come in useful later on when I add more maps. I also want to do a little thing where every map is its own globe that kind of shows the outline of the map. I think it’ll look cool.
• Wave Control: I changed the wave logic to make it be controlled by the player. I was inspired by Bloons TD 6, and I think this makes it much better. Now, the player has as much time as they need to prepare for the next wave, or if they are feeling good they can just call in multiple waves and get it over with.
• Game Icon: I made a game icon, a shield with a golden cross and ruby in the center. I made it be the icon for the window, and it will be the icon for the .exe file when it’s time to ship.
• Canon: I added a cannon turret. It’s still kind of buggy, but the idea is that it will leave an explosion and that will also be the AoE so it can shoot multiple enemies, kind of like for crowd control. Generally, I really need to spend some time balancing the game, but I think that will come at a later time.

I’ve kind of gotten into a slump, mostly because of school, but I think I’m back on track to finish this by the 30th of this month. Though I gotta say, it’s genuinely been slog to work on this now. I think I’m burning out

Anyway, for the updates:

• Turret anti-aliasing: To fix the issue of turrets looking terribly when rotating, I used a new function that zooms and rotates the sprite, but also applies anti-aliasing. I can set the zoom scale to 1 and it will rotate the sprite but also anti-alias it. The jaggedness seen in other demos was because the actual map is rended in very low resolution (360x240) and then scaled up.
• GUI Makeover: I have given another makeover to the GUI. Now, most of it in the main game is a sleek semi-transparent black surface. I did this mostly because I couldn’t settle on a particular theme, and I didn’t know how to go about drawing such large sprites while still looking good.
• Waves: I finally got around to adding waves. They are a little buggy, but I ended up making a dictionary structure for the maps and put them in one big dictionary. This way, I can define which enemies spawn in which order, the interval between waves, etc. Enemies and turrets are also in their own dictionaries.
• Health: I added the health mechanic! It will now check if the health is equal or below 0 and send the user to a game over screen. Those screens will eventually get improved.
• Menus: I added a main menu, mostly because I had people trying the game, and it had to happen at some point. As of right now I am working on a map selector that harnesses that maps dictionary from earlier. (I did the devlog now because I was afraid of getting to 10h )
• More menus and turrets: I added a ballista tower, which is slower but has higher range. I still have to balance it some more, and make a bolt projectile, and also probably make the tower control the damage instead of the arrow. That way I can subtract health from the enemy directly, which would fix an annoying bug where the turret shoots but the bullet doesn’t collide with the enemy, so it just stays there until it collides with another enemy. There is also another slime (the red slime) which is faster. This is to force the player to have at least 2 turrets.

Quite a bit of progress!

• Pixel art revamp: The pixel art has generally improved massively. I actually took the time to get some inspiration from Google and worked on the tileset. It now includes a lake and also generally just looks better, with borders around the paths. It did take a lot of time, though. I also implemented animations for this, for the slime, and perhaps for the crossbow too. I also made a little card container for the top 2 stats.
• Waves: I added waves! It’s now technically a fully playable tower defense game, I guess. As of right now it’s going to crash as soon as it gets farther than Wave 3 because I don’t have anything to do after it, but soon I will add another scene for that.

Lots of progress again! This one was slightly more in the background, as I started a little bit of housekeeping:

• Transition from Rects to FRects: FRects are the same thing as normal Rects, except that they allow for floats. This didn’t really have an impact on the game other than making it easier to work with vectors for positioning, as they also use floats.
• UI Changes: I changed the positioning aspect of the UI. I recreated the Rect placement system of pygame, where you can select a point (eg. top left, center, midbottom, etc.) to use to position the rect. This is very flexible, and I copied it. Now, I can do things like place text with much more ease. I also changed the colors of the UI to make it darker and overall nicer. I made it so that the user had to select a turret and then go to a menu to see the cost and other attributes of it, which will be better for the future.
• Coins: I added coins, which will be the temporary currency when inside the game. This will be used to buy towers and such. Outside the main game, I am planning to create another one that is used to buy skills and stuff, just to make it more realistic.

It took a while, but there have been some pretty big improvements.

• Transition to 1440x960px: I eventually found that being limited to 360x240 was going to be very limiting, specially with text because at low resolutions it looked like a jumbled mess. Thus I embarked on a pretty hard journey (not hard in retrospect) to figure out how to change the resolution but also keep the pixelated style without having to draw sprites at 4 times the resolution. The solution I ended up finding was to store a scale factor of 4 (360x4=1440, 240x4=960), and then scaling a separate surface to that resolution. Now, a surface is created with the same dimensions as the map, and everything is drawn to that surface instead of the map (I used to draw enemies, turrets, bullets, etc. onto the map because they moved together), and then that surface gets scaled. This allows me to keep the pixelated graphics on the actual game, and have crisp text on the GUI. For the offsets, I just moved the function that translated the screen coordinates to map ones from the map to the scene, and then adjusted it to take in the scale factor. Everything else works pretty much the same, as its only the image and mouse clicks getting scaled instead of rectangles. I scaled the button sprites to 32x32 to make them easier to draw, and then I have it in the config to scale them to 64x64. I decided to do that mostly for ease, because most of the other sprites are around that resolution anyway.
• Turret placement: I added more buttons to the GUI and added turret placement. The GUI itself is always going to be kind of janky. I moved it into its own class so as to sort of clean up the code in the main scene, but now the GUI manager does weird things like self.scene.game.screen.width which isn’t very pretty. It’ll do, though. I track a variable storing the turret to be placed (None if it’s not in that state) and a variable that stores whether it can be placed. I check for collisions between the path tiles (I knew it would be useful!) and the sprite to check if it can be placed. I also modified the draw function of the turret to make it red or green depending on it.
  GUI: Generally, for the GUI, I keep a state from an Enum (basically a fancy way of storing a string for a state), and then change the UI according to that state. I designed it in a way where it only rebuilds it on command, so it won’t rebuild the whole thing every frame, in hopes to save some sort of performance.

Overall, some very good progress, even if it’s not 100% visible!

I decided to just write the GUI from scratch. This is kind of uncharted territory for me. I tried using pygame_gui but it felt really restrictive and the use of a json file for customization is absurd to me. I made a basic element abstract class so that all elements must have an update and draw method. I then made a button class and a container class. All elements have an ID, and when a button is clicked it sends out a pygame event, which is a feature I did like from pygame_gui. I think I will end up eventually making an UI manager class, as handling the state within the scene is getting clunky and weird.

I COULDNT EDIT THE SHIP POST BUT THERE IS NO WEBSITE ANYMORE JUST RUN bishopviz -d TO OPEN THE WEBAPP

I’ve recorded a demo, published it on BOTH Streamlit and Pypi, fixed any bugs, and added a file input option. I think I’m ready to ship.

I think I’m done with the data part. Lowk, it looked better in my head, but this was more of a practice in Streamlit and plotly than actual data analysis. I wanted to make it so that there was just an option in the CLI and then users could put it to start the server and visualize the data they just put the option. Unfortunately, due to the way Streamlit works, I just made it a separate app. This way users can launch the command from the cli and it can also be deployed as a standalone app.

I’ve got a lot of the cosmetic stuff done.

I moved the algorithm into its own class, which overall made it easier to track certain variables like its position. For the animate option (next paragraph) I had to make a move function that ran 1 generation of the algorithm, so that I could print between frames.

I made an animate option that takes in an amount of seconds and then displays an animation as the bishop moves. The only complicated part about this is that it uses an escape code to move the cursor back up, so as to give the illusion that the same printed text is moving.

I made a character set option and then got ChatGPT to generate some character sets. These follow the convention set by the actual algorithm, in which it’s just 17 characters, with 0 being empty, 15 being the start, and 16 being the ending position. I also added a bishop key so that during the animation it would show where the bishop was. To accomodate the Katakana and emoji options (I didn’t show Katakana but the emojis do show it), I had to modify the draw function to double the width of the graph. It’s still 17, just getting printed as 34 or so.

I got colors too. I just made the same dictionary as a character set but with the color names (I’m using click for the CLI, and it has an API for coloring text) as the values. I then modified the draw function to use the value of the dictionary at the key corresponding to the tile as the foreground if the colorize option was enabled.

Overall, the project has turned out pretty nice, and I will be working on the data visualization part next!

I got the algorithm working, so that’s pretty much half the project done. I wrote the draw function with a character set argument, so that it is possible in the future to change what characters it uses.

I’ve probably progressed more in these ~6.25 hours than the rest of the project combined.

• Fixed the map dragging boundary checks. This was just a matter of separating the if statement into one for each axis. Now, even if the map won’t move on the y-axis, it can move on the x-axis, for example.
• I added an enemy. This was also pretty simple. They take in a path instead of a position, and their initial position is just the first index of the path (the path is a list of coordinates that they walk to). Vector math made this much easier, as I could just subtract the current position of the enemy from the target, and multiply it with movement speed to move it. The enemy is actually a parent class, and the specific slime in the video is a very simple subclass of it that just has some stats. Default enemy behavior is handled in that parent class.
  • I made a customizable health bar class. The cool part about it is that it uses linear interpolation to change its color as the health changes relative to the maximum.
• I made a ballistic projectile parent class and an arrow subclass. It takes a position and a target, as well as other stats, and uses vector math to move to the target. When it hits an enemy it takes health from the enemy and then ceases to exist.
• There is a turret class and a crossbow. The turret takes a projectile class (the crossbow takes the arrow, for example). It will make a new instance of the projectile when shooting. It has a circle for a range of effect, and it will point to and shoot at enemies within the circle.
  • The r key will toggle between drawing the areas and not.

Quite a lot of progress!

I decided to give up on the isometry because I wasn’t really getting anything done. I have gone back to using a 2d map instead.|

• The map is made with the Tiled Map Editor (https://thorbjorn.itch.io/tiled) and saved as a JSON file.
  • Tiled is good for visually building maps but a pain to work with. I’d much rather write a map editor from scratch, genuinely. I might do it at some point, honestly.
  • The map is actually split up into 3 layers: the ground, where turrets can be placed; the path tiles, where enemies will walk; and the path polygon, which is a line that the enemies will follow. This allows me to have separate path and ground groups which will simplify turret-path collisions later. In theory, I will be able to make the enemies follow the polygon, too.
  • I had to write a whole function just to parse the map JSON files. It organizes the layers into a dictionary of keys and 2-dimensional Numpy arrays. For the path polygon, it converts it from a list of dicts to tuples. It also removes any other inconsistencies with the original file and only keeps the important stuff.
• I made the map bigger than the screen itself so that it is draggable. The checks for boundaries are kind of buggy but it’ll do for now. This was just a matter of keeping a variable to track if the map is being dragged, keeping an offset, checking for boundaries, and checking for mouse movements.

I know this was kind of a setback, but real progress can be made now!

Turns out, rendering isometric grids is pretty hard! I followed a tutorial by DaFluffyPotato on isometric rendering which let me understand the drawing part, but there are going to be some issues with the grid system in the future. I had an issue in which the grid wouldn’t draw half of itself, and it was because it was drawing everything to the right of the top tile outside it. I got it to work by multiplying the grid width by 2 and then adding an offset, but it’s kind of a band-aid and I want to research more into how to actually solve it. I did actually draw the sprites myself, though, and I have a grass block that looks really nice but that’ll be for later.