Sorry I haven’t posted in a while. I was preparing assets for the Steam page. It might be ambitious, but go big or go home, right?

As promised, I’ve released a demo with seven playable levels. Play it here.

I’ll soon be releasing a demo with playable levels. That demo needs a title screen that introduces the game, so I thought it was a good opportunity to create a logo. It looks like this:

I couldn’t find a font that worked well, but Bungee Hairline came close. I liked it, but felt the weight was too light. The only thicker style, just called Bungee, was much too heavy, so I typed the title out in Hairline and expanded it in GIMP. The corners are more rounded than in Bungee, but I think it works. I considered making a vector or editing the font, but I’m much more familiar with GIMP.

I’ve been making some playable levels so I can publish another demo. All of the levels before now have had programs spawning with only one sector, the head, and only gaining sectors when they move. This has made it easy to add sectors to the back of an array so they can be removed when a program is attacked.

Some of the levels I’m making have programs spawning with many sectors. I initially solved this by adding sectors to my two dimensional level data array, then adding those sectors to each program’s sector array when I iterate through the level data to build the level. This worked, but was flawed. It would usually add sectors in the wrong order, meaning if a program was attacked before it had replaced all its sectors by moving, it could be left with floating sectors not connected to the rest of the program:

The purple sector to the right of the yellow program is part of the purple program on the right. It can be attacked and functions just the same as the other sectors, but isn’t attached to the program. This might create a mess of floating sectors that detracts from the game.

My solution is to use my Dijkstra function to work out how far each sector is from the program’s head, then arrange them so the furthest get removed first. It looks like this (bear in mind the program’s head was in the top-right corner when it spawned):

I added a while loop so that it iterates through turns rather than just having one turn then stopping. It doesn’t detect when either the player or enemy has won, but other than that it mostly works. Video:

After this my plan is to polish a few things, then make and release a few playable levels.

I’ve added a few things to the UI. I made the program list slightly smaller so I can fit in the End turn and Save game buttons. The program title at the top felt redundant when I already have the program title under the action buttons, so I removed it. I used the extra space to add a “Moves left” attribute. I changed “Current size” to just “Size” and put it above “Max size”, so I could shorten the spacing between the colons and numbers, giving enough space for a proportionately sized program icon. The “Range:” written under the program title was redundant without an attack selected, so I changed it to say “Friend” or “Enemy”, which is much more useful information. Picture:

I’ve successfully made the enemy programs move and attack the player’s programs autonomously. They use my Dijkstra function to work out the shortest route to get within attacking range of a player program, then take that route and attack. It updates when the grid changes and avoids obstacles. Obligatory video:

This is significant. The enemy AI is probably the hardest part of the game to create. At least one person abandoned his Nightfall Incident based project after hitting a wall with the AI. It’s quite simple, and I could always improve it, but the fact that I’ve now got it working means I’ve overcome probably the most significant hurdle. It means I’m much more likely to complete this game and succeed where at least eight other people have failed.

I haven’t posted any updates in 8 days. That’s because I’m writing the AI for enemy programs. It’s probably the hardest part, and involves abstract things like working out routes to the player’s programs, deciding which one to attack etc., so I can’t easily post videos or screenshots that show what I’ve done.

Currently I’ve gotten as far as working out which squares the programs could move to to get within attacking range. Now I’m writing a function that decides which of those squares to move to and which program to attack, based on how many sectors the player’s programs have, the attacking strength of the enemy program, and the health of the enemy program. After that I’ll make the attacks functional for both player and enemy programs, then I’ll probably be able to make a few playable levels.

The enemy AI is unique in that it’s harder to replicate than other things. For almost everything else, all the levels, programs, etc. in the original Nightfall Incident, I can clearly see the information I need just by running the game. (I completed it so can access all the levels) For the enemy AI, I can see what programs do and where they move, but I can’t see the logic that made those decisions. This means it’s nearly impossible to exactly recreate the AI.

Instead I’m creating my own that moves towards programs in a similar way, but tries to be smart with deciding which programs to attack. For example, imagine there are two player programs with two and three sectors respectively, and two different enemy programs with attacks that remove two and three sectors respectively. If the enemy programs choose their victims arbitrarily, it may well end up with the three sector enemy program attacking the two sector player program and vice versa, killing the two sector program but leaving the former three sector program with one sector. However, if it’s smart about its decisions, the three sector enemy program will attack the three sector player program and vice versa, killing them both and winning the game for the enemy.

I used my Dijkstra’s algorithm implementation to add squares that make it clear where programs can move:

The translucent overlays are on squares that the Hack could get to within three moves. It takes obstacles into account, and updates as things move and the grid changes.