next »

[Jayesh]

Greetings,

I'm excited to share prototype of my 2D Tower Defense game Fold Wars. You can play it on itch here.

I've been a fan of RTS (Age of Empires, StarCraft) and especially Tower Defense (Defense Grid 2). I always felt that there is more that can be done in this kind of game, especially in terms of visualization of strategy. For long time I thought about making an RTS game of my own, but the task seemed daunting and too big for my skillset. Last year I came across some 2D RTS games like Infested Planet, Mini Metro. This inspired me to think about my ideas again with a more manageable goal. Thus Fold Wars was conceived.

I've worked on Fold Wars for 2-3 months so far and only released a playable demo recently on itch. It has since been updated and now has 2 levels that you can play. I haven't yet reached the part of novel ways to visualize strategies, but that's coming. So far it's a basic shell for a traditional tower defense game, with some enjoyable gameplay. I'll be posting frequent updates in devlog here and on itch.

The game is playable in browser and written using HTML5 tools - Typescript, Pixi.js as rendering library, Howler.js for audio, artwork done in Inkscape, animation done in Spine, music composed in VCVRack+Audacity.

I would love to hear about your thoughts if you play it. Also if you have any comments on generic RTS/tower-defense genre, do chime in.

Cheers!

[Jayesh]

Added a new level today (3rd so far), with a new enemy and new tower kind. Here's how it looks





Since I just started this devlog, I'll list all enemies and towers in Fold Wars so far.



Towers:
Gun - typical workhorse tower, with normal abilities
Canon - Fires more lethal ammo than Gun, but rate of fire is low, it costs more. Its range is longer than Gun.
Laser - Fires almost as lethal ammo as Canon, but rate of fire is very high, it costs more. Also its ammo is somewhat ineffective against shield. Range is longer than Gun.

Enemies:
Walker - typical enemy
Bouncer - A powerful enemy that's stronger than Walker, has more shield, but moves slower
Sprinter - Enemy that moves faster than Walker, has somewhat weaker shield, but same health as walker.

A combination of these two, combined with rate at which they are deployed from the enemy ship opens up fun strategy possibilities.

[Jayesh]

Building towers in FoldWars now automatically creates walls, thus giving a better visualization of your strategy. Also added lot of waves in each of the level. Moreover each level now has 3 difficulty settings. Spent whole afternoon playing with parameters of each level to create appropriate difficulty levels. It was fun play, but now I'm exhausted. The parameters for 3rd level could use more tuning.

Also discovered that I need to pay attention to memory consumption. As I added deep waves of enemy, it stressed the browser a lot. Near the end of some hard levels you might see some hiccups. Fortunately I've identified places where I can save on memory. I'll work on it tomorrow.

Made changes to the location of Tower Menu. It now shows to the side of the screen, thus avoids obstructing the view of the playing field. This is very useful when you get used to keyboard shortcuts. It might be confusing for beginners, but UX design principles say the UI should always be optimized for intermediate users.

Also there's a subtle change in the behavior of towers. The Canon and Laser towers now have one special feature that a gun doesn't have. When there are multiple enemies within the range of the tower, which one it should choose next? This decision has impact on the strategy. If the decision is made at random, then the tower may ignore enemy carrying gold - which is more urgent to deal with. That's the difference in behavior of Gun and Canon/Laser. The later are smart and choose the enemy carrying gold. Mind that while planning your strategy.

[Jayesh]

After implementing levels with hardest difficulty that have hordes of enemy waves, I hit performance problems. The browser would become visibly unresponsive near the end of the level. So today I spent debugging those problems. I profiled the entire level 1 run in the Chrome dev tools memory profiler (as can be seen in the screenshot) at every step. At the end of the day, I've managed to get level 1 running without any hiccups at 60fps until the very end. Here are some things I found and fixed. Might be helpful to other HTML5 game developers.

• It was clear that the performance problem was proportional to number of spawned enemy units (I call them ghosts in the code). Since I create a Javascript object for each of them, I thought it was too heavy. The heaviest part of it was the Spine object (the JS library from Spine animation tool). It was no longer necessary to use spine objects for each ghost, because they don't have any significant animation. So I removed them and replaced them by simple pixi container. Unfortunately, this didn't help the problem a bit.
• To further investigate I started disabling various parts of the code. At times replaced ghost objects, by only a single pixi sprite object. That didn't have any performance impact, so the problem wasn't with rendering or Pixi.js. But during one of these trials, I found that disabling the sound was saving the memory quite a bit. I'm using Howler.js for the audio, but I'll come back to this later. After disabling audio, I could play the whole level, but still it was quite slow near the end.
• Another thing that was occupying memory in each ghost object was certain array that keeps the path of the ghost. All ghosts share some common paths, therefore they keep a copy of the common path with them. But my ghost movement algorithm was modifying each path (unncessarily in retrospect), therefore I had kept a deep copy of the path in each ghost. After some reflection, I could easily modify the code to not modify the path, thus refer to the single master copy of the path without duplication. This change did have positive effect. The entries in the memory profile tree, that were attributed to the path code, were gone now.
• After these changes when I ran the profiler again, it ran better all the way to the end. It was at this point that I found an unexpected entry at the top of heap profile tree. It was in the analyse() method of my collision detection system. My collision detection system is pretty primitive and makeshift. I go over all ghosts and all towers in every game tick and then compare if they are within each other's range. The performance problem wasn't due to this computation, but due to the data structure in which I was saving this in-range relations between various towers and ghosts. I was naively using a hashmap. If ghost A is within range of tower B, then there will be a key in the hashmap for "gAtB"! Natually, when the hordes of ghosts were spawned, a lot of memory was being allocated to the strings that were used as keys in this map. When I first coded this one, I knew it will have to be replaced, but had forgotten about it. Today was the day. Since the visibility information is 1-bit information, there was significant scope for saving memory here. I put together a 2D grid of bits implemented on top of Uint8Array, rewired the ID system of ghosts and towers and came up with pretty lean mechanism to record the visibility data.
• The collision system change saved a bunch. Now was the time to take care of audio. I don't know what Howler.js is doing or if I'm using it wrong, but after a bit of reading I figured I don't need a library to use HTML5 audio. Even this simple tutorial is enough to implement what my needs are. Took me 10 minutes, to replace howler code. I would like to spend more time on this, but this audio code doesn't seem to have adverse effect on memory usage the way Howler had.

Very glad to have fixed this. I'll deploy the new build tomorrow after some more testing.

(Cross posting from Itch devlog)

[Jayesh]

Last week I spent some time rewiring the path computation algorithms for the enemy units. There was some scope to save both computation and memory by changing when and how the paths of each enemy unit are computed. The path computation is done by BFS analysis, as is typical for any tower defense kind of game. Once the grid has been computed though, each enemy can use it to compute its path. So far I was computing the entire paths from source cell to destination cell for each enemy and storing them at the start of their lifetime (as you can see in the "before" part of attached visualization). When the terrain changes due to tower addition/removal, this path is discared and new path is recomputed for each enemy unit. This seemed like a waste of resources and that's where I found some scope for optimization.

In the latest version, each enemy unit only computes the path 2 cells ahead of itself. This computation is obviously cheaper and also the results are small in length (the "after" part in the visualization). Therefore the discarding of memory will also be little when terrain changes. Using the heap profiler timeline in Chrome dev tools I could see that the memory churn was visibly smaller with these changes.

This allows the game to scale for larger number of enemy units. This in turn enables possibility of more number of waves with more number of enemy units. a.k.a more fun!

(cross posting from Itch Devlog)

[Jayesh]

Here's a first installment of strategy visualization technique once you have finished the level. It's a composition of plots that let you see your gameplay as a whole. Right now the plots are unlabeled, which I will fix soon. The continuous line indicates your score as it increases against time. The staircase plot indicates the number of towers you build over time. The background gradients are waves of enemies. The width of each gradient tells how long it took to deploy, while the intensity of gradient tells the number of enemy units consisted in that wave.

I've also revamped the GUI architecture. There are no visual changes to the end user, but there is now a consistent SVG based framework for menus and screens.

Level 1 and 2 have been recalibrated to make them more interesting. Give them a try (especially the hard difficulty setting)

Play now

[Jayesh]

Tower defense strategy is all about placing towers at strategically right positions at right time. The spatial strategy is quite clear by looking at the map. But the temporal strategy is not. In other words, it's not obvious how the tower performs over a span of time. Or among all towers which tower is performing to max efficiency and which is not. Here efficiency is defined the fraction of total time that the tower spends actively firing at the enemy. If it has lower efficiency, then that means the tower is placed farther away from the main enemy path and may not be worth the resources put into it (however that's not always necessarily true. Some towers are placed just to push enemy away from them and take longer paths).

The new feature, as should be evident from the screenshot gives you just this information. You turn it on by clicking on a button in the tray near right bottom of the screen.

[Jayesh]

Today's build comes with a new level - number 4. This one has twice the resolution of the map, that means there is lots of real estate to build towers. This will allow very deep waves. More variety of possible startegies. Overall, more fun!

One problem I faced with higher resolution was tweaking the enemy artwork so that it doesn't look too tiny. To achieve that I simplified the ghost designs somewhat.

Also, I had to change the Tower addition sequence a bit. Before the grid used to show all the locations where new tower could be built and it would not show a cursor where tower cannot be built because otherwise it will block the only path that enemy has available to reach the gold. However to come up with this information requires some expensive analysis, which takes long time to run on all the cells of the grid; especially when the grid is now 4 times as big. So to avoid this issue, the game no longer removes cursor from the potential bottleneck locations. It checks for the bottleneck condition after player has asked to build a tower there. Since this concerns only one cell, the analysis is cheap and doesn't take any time. If the bottleneck exists, then user is shown a warning like this.

[Jayesh]

The ship is now very informational. It gives the player a peek at the size and speed of the upcoming waves. I completely redid the design by doing all the animation in code. Previously I was using Spine for the ship design. But that approach had some limitations from the programmability point of view. It's fun to animate by writing code.

[Jayesh]

New animation in ship that shows how much gold has been hijacked by the enemy and successfully carried to the ship. Also now the ghosts carrying the gold have a special glow around them. This makes it really easy to track where on the map the gold is at any moment. This is very important on the new maps where the towers and ghosts become crowded very fast.

[Jayesh]

Today's update brings revamp of tower artwork. The new tower sprites are minimal, crisp, distinguishable, work at both normal and double resolution. Also updated the drawing of walls between adjascent towers. Fixed some bugs in wall drawing algorithm which used to leave out some sections without walls.

[Jayesh]

Hello all,

I haven't updated this devlog in a while, but I've been constantly updating the game. In past few months I've added new mechanics, new enemy types, new levels and a sweet new color scheme.

There are now 8 types of enemies to fight against



There are total 12 levels now. The color palette has been re-designed for more interesting gameplay where different elements can be distinguished by virtue of their differing shades.



And the game is now available to play on Kongregate!

https://www.kongregate.com/games/blumath/fold-wars

Try it out!

[Jayesh]

Added 4 new levels to Fold Wars. They feature new mechanism of multi-ship attacks. It leads to many interesting strategic choices.



The game is now also available on Itch.

https://bluemath.itch.io/fold-wars