Using the Free Pascal IDE for a week

Code can really be written with any text editor that you're comfortable with. I tend to use Vim for quick edits and writing notes, and on Linux I occasionally use Geany or Mousepad. But when you want to do more than quickly update a few files, you need a full Integrated Development Environment (IDE).
An IDE understands the language that you're writing in, and can run additional tools like a compiler and a debugger from the same environment.

The most full featured IDE for Free Pascal, bar none, is Lazarus. The ease with which you can write, refactor, debug and compile programs in Lazarus makes me miss it when I have to write code in another language. It's fast and perfectly suited for the task... except in one instance.

Lazarus is designed for coding GUI applications, but recently I've spent most of my free time writing a terminal based game. It used to be possible to run a terminal session 'attached' to Lazarus, so that it could be debugged from the IDE, but since a previous update this always seems to fail on my PC. I can still use Lazarus to write my code, but when I encounter an error I need some other way to diagnose it.

Introducing FP IDE

I'm not sure what the rationale is for maintaining the text mode FP IDE. It seems kinda quaint in 2022 to maintain a recreation of the old Turbo Pascal editor, but I'm so glad that it's there. The IDE might not have all the bells and whistles of something like Lazarus, but it's lightweight, easy to use, and reliable. I first learned Pascal back in the Borland days, so the IDE does feel familiar to me. Although I'm not sure how a younger programmer, encountering it for the first time would feel about it. Without the haze of experience and nostalgia informing their opinion.

Regardless, it comes with Free Pascal and runs in the terminal. It does require a little setting up first though. Note, I'm running Linux here but the same should work in Windows with a little tweaking to use the correct file paths. Also, I've found the best Linux terminal to run the IDE in is Xterm. Other terminal emulators seem to catch your keyboard commands for their own menus.

Setting it up

The first time that you run FP IDE it creates a couple of config files in the starting directory, fp.cfg and fp.ini. The first thing that you notice when opening the IDE is the retro, blue colour scheme. The second thing that you'll notice is that it doesn't actually compile Pascal programs out of the box.
I'm not sure why this is the default setup, but you need to tell the IDE where to find the Free Pascal files on your system. A quick Google search shows that this step trips a lot of people up, so let's kill two birds with one stone and get both of these things resolved.

Open fp.cfg in a text editor and you'll see three sections:

#IFDEF NORMAL
#IFDEF DEBUG
#IFDEF RELEASE

These correspond to the different build profiles that you'll use. Personally, I spend all my development time using the debug profile, and then only use release at the very end of my development cycle.

In each section, add the following lines:

 -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget
 -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/*
 -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/rtl

You can also add this in the IDE itself in Options > Directories > Units, but it's a little quicker to copy and paste this in a text editor.

Unlike Lazarus, the FP IDE doesn't use 'Projects' where all of a programs files are managed. Instead it deals with directories/folders. If the program that you're working on has files stored in subfolders, explicitly add them here. Each line begins with -Fu followed by the full path to the directory, with no space after -Fu.
As an example, here's my fp.cfg file below.

# Automatically created file, don't edit.
#IFDEF NORMAL
 -TLinux
 -Mfpc
 -Sg
 -Si
 -Os
 -CpATHLON64
 -OpCOREI
 -Fu/home/cypher/Development/MyProg/
 -Fu/home/cypher/Development/MyProg/AdditionalUnits
 -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget
 -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/*
 -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/rtl
 -g-
 -p-
 -b-
#ENDIF

#IFDEF DEBUG
 -TLinux
 -Mfpc
 -Sg
 -Si
 -Sa
 -Cr
 -Ci
 -Co
 -CR
 -Os
 -CpATHLON64
 -OpCOREI
 -Fu/home/cypher/Development/MyProg/
 -Fu/home/cypher/Development/MyProg/AdditionalUnits
 -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget
 -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/*
 -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/rtl
 -g
 -p-
 -b-
#ENDIF

#IFDEF RELEASE
 -TLinux
 -Mfpc
 -Sg
 -Si
 -CX
 -Os
 -CpATHLON64
 -OpCOREI
 -Fu/home/cypher/Development/MyProg/
 -Fu/home/cypher/Development/MyProg/AdditionalUnits
 -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget
 -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/*
 -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/rtl
 -XS
 -g-
 -p-
 -b-
#ENDIF

Some Quality of Life improvements

The next steps aren't necessary in order to use the IDE, but I find that it makes it a more comfortable environment to work in.

If you're happy with the blue colour scheme, you can ignore this step. Personally, I prefer something darker so I put together my own colour palette. It's incomplete, but it's good enough to use day to day.
View the file at https://github.com/cyberfilth/FP-IDE-theme and paste the [Colors] section into your own fp.ini file.

The next thing that I do is download the help files, so that I can access them through the IDE's built-in help viewer. The HTML documentation can be downloaded from https://www.freepascal.org/down/docs/docs-canada.var then add them in the IDE by going to Help > Files and adding the path to the HTML files.

Now the IDE is set up. It took a little more work than opening Lazarus for the first time, but now I can find bugs in my code a lot easier. Until now I've been writing code in Lazarus and firing up the FP IDE whenever I need to debug something. I did wonder though if I can just use the FP IDE for everything.

Since I'm currently writing a roguelike game, I thought that I'd open it up in the IDE. Before doing that, I amended the main filename from the Lazarus format to plain Pascal. That just means changing the suffix .lpr to .pas.  
Once the main program file is opened up, select it as the primary file.

One of the main differences in the interface, compared to Lazarus, is that instead of a tabbed interface it has a series of windows. With the right font size, I actually prefer this interface as it means that I can see several related files on screen at once.

The biggest thing that I'm missing so far is a good auto complete. The IDE will offer suggestions for completing Pascal keywords but, unlike Lazarus, it won't try to autocomplete your own variables or procedure names.

Regardless, I'm going to try and restrict myself to just using this IDE for the next week to see if I can still use it for my hobby project. My codebase is currently about 17,000 lines of code and I'm curious to see what it's like to navigate it using the IDE... wish me luck!

Pathfinding with smell maps

 Enemies in Axes, Armour & Ale find the player using various methods, from calculating a Bresenham line to the player, heading towards the players last seen location, or even just wandering aimlessly around the map.

One of the methods used is a smell, or distance, map. This is much easier to implement than A* star pathfinding or Dijkstra maps. It simply takes the players location as the starting coordinate and floodfills the walkable areas of the map with numbers that increment the further away that they get from the starting square. This is done using a Breadth First Search.

Take the simple map below, I've added point A and point B.

#  #  #  #  #  #  #  #  #  #  #  #  #  #  #  #  #  #  #  #  
#  .  .  .  .  .  .  .  .  .  .  .  #  .  .  .  .  #  #  #  
#  .  #  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  #  
#  .  .  #  .  .  #  .  #  #  .  #  #  .  .  .  .  #  .  #  
#  .  .  #  .  #  .  #  .  #  #  .  .  .  #  .  .  .  .  #  
#  #  #  .  #  A  .  .  .  .  .  .  #  .  .  #  #  #  .  #  
#  .  .  .  .  #  .  .  #  #  .  .  .  .  #  .  #  .  #  #  
#  .  #  #  .  .  .  .  .  .  .  .  .  .  #  #  #  .  .  #  
#  .  .  #  #  .  #  .  .  .  .  .  #  .  #  .  .  .  #  #  
#  .  #  .  .  .  #  .  .  #  #  #  .  .  .  #  .  .  .  #  
#  .  .  .  .  #  .  .  .  .  .  .  .  #  .  .  #  .  .  #  
#  .  .  #  #  .  .  .  .  #  .  .  .  .  .  .  .  .  .  #  
#  .  .  .  #  .  .  .  .  #  .  #  .  .  #  .  .  #  .  #  
#  .  .  .  .  #  .  .  .  .  .  .  .  .  .  .  .  .  .  #  
#  .  #  #  .  #  .  .  .  #  #  .  .  .  .  .  .  .  .  #  
#  .  #  .  #  .  .  .  .  .  #  .  #  .  B  .  .  .  #  #  
#  .  .  .  .  #  .  .  #  .  .  .  .  .  .  #  .  .  .  #  
#  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  #  
#  .  .  #  #  .  #  #  #  #  #  #  #  #  .  .  .  .  .  #  
#  #  #  #  #  #  #  #  #  #  #  #  #  #  #  #  #  #  #  #

Point A is the target, the player in this instance. 

The map is then filled like this:

99  99  99  99  99  99  99  99  99  99  99  99  99  99  99  99  99  99  99  99  
99  24  23  22  21  20  19  18  17  16  15  14  99  12  13  14  15  99  99  99  
99  25  99  21  20  19  18  17  16  15  14  13  12  11  12  13  14  15  16  99  
99  26  27  99  21  20  99  18  99  99  15  99  99  10  11  12  13  99  17  99  
99  27  28  99  22  99  2   99  4   99  99  7   8   9   99  13  14  15  16  99  
99  99  99  8   99  0   1   2   3   4   5   6   99  10  11  99  99  99  17  99  
99  9   8   7   6   99  2   3   99  99  6   7   8   9   99  99  99  23  99  99  
99  10  99  99  5   4   3   4   5   6   7   8   9   10  99  99  99  22  23  99  
99  11  12  99  99  5   99  5   6   7   8   9   99  11  99  23  22  21  99  99  
99  12  99  8   7   6   99  6   7   99  99  99  13  12  13  99  21  20  21  99  
99  11  10  9   8   99  8   7   8   9   10  11  12  99  14  15  99  19  20  99  
99  12  11  99  99  10  9   8   9   99  11  12  13  14  15  16  17  18  19  99  
99  13  12  13  99  11  10  9   10  99  12  99  14  15  99  17  18  99  20  99  
99  14  13  14  15  99  11  10  11  12  13  14  15  16  17  18  19  20  21  99  
99  15  99  99  16  99  12  11  12  99  99  15  16  17  18  19  20  21  22  99  
99  16  99  20  99  14  13  12  13  14  99  16  99  18  19  20  21  22  99  99  
99  17  18  19  18  99  14  13  99  15  16  17  18  19  20  99  22  23  24  99  
99  18  19  18  17  16  15  14  15  16  17  18  19  20  21  22  23  24  25  99  
99  19  20  99  99  17  99  99  99  99  99  99  99  99  22  23  24  25  26  99  
99  99  99  99  99  99  99  99  99  99  99  99  99  99  99  99  99  99  99  99

Using this, an enemy can track the player simply by looking at the number on their own square and moving to a square with a lower number.

#  #  #  #  #  #  #  #  #  #  #  #  #  #  #  #  #  #  #  #  
#  .  .  .  .  .  .  .  .  .  .  .  #  .  .  .  .  #  #  #  
#  .  #  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  #  
#  .  .  #  .  .  #  .  #  #  .  #  #  .  .  .  .  #  .  #  
#  .  .  #  .  #  .  #  .  #  #  .  .  .  #  .  .  .  .  #  
#  #  #  .  #  A  X  X  .  .  .  .  #  .  .  #  #  #  .  #  
#  .  .  .  .  #  .  X  #  #  .  .  .  .  #  .  #  .  #  #  
#  .  #  #  .  .  .  X  X  .  .  .  .  .  #  #  #  .  .  #  
#  .  .  #  #  .  #  .  X  .  .  .  #  .  #  .  .  .  #  #  
#  .  #  .  .  .  #  .  X  #  #  #  .  .  .  #  .  .  .  #  
#  .  .  .  .  #  .  .  X  X  X  X  X  #  .  .  #  .  .  #  
#  .  .  #  #  .  .  .  .  #  .  .  X  X  .  .  .  .  .  #  
#  .  .  .  #  .  .  .  .  #  .  #  .  X  #  .  .  #  .  #  
#  .  .  .  .  #  .  .  .  .  .  .  .  X  X  .  .  .  .  #  
#  .  #  #  .  #  .  .  .  #  #  .  .  .  X  .  .  .  .  #  
#  .  #  .  #  .  .  .  .  .  #  .  #  .  B  .  .  .  #  #  
#  .  .  .  .  #  .  .  #  .  .  .  .  .  .  #  .  .  .  #  
#  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  #  
#  .  .  #  #  .  #  #  #  #  #  #  #  #  .  .  .  .  .  #  
#  #  #  #  #  #  #  #  #  #  #  #  #  #  #  #  #  #  #  # 

This method of pathfinding is less CPU intensive than other methods, I also only update it every 3 turns. It can be used by all NPC's on the map but can only be used to find the player, not other NPC's. For the way that Axes works though, this is ideal.

My current development IDE

I've recently reconfigured an old Dell laptop for development work and thought that I'd post my current setup. I love reading about how other people configure their systems and I'm always open to suggestions.

I already have a Windows 10 PC, that I only really use to test Windows versions of software that I've compiled, so my new dev laptop has Linux installed. I've been using Linux as my primary OS for 19 years and I'm comfortable working in it, I occasionally have to dip into the Windows world, due to work, but usually find myself frustrated with its limitations.
Currently Xubuntu is my favourite distro, although in the past I've used SUSE, Slackware, Vector, Slitaz, CrunchBang (my favourite for a long time) and Bodhi.
Xubuntu isn't as lightweight as some of the Linux flavours that I've used in the past, but it works straight out of the box with most hardware.

Vim

I've recently decided to use the Vim editor for all of my coding. Again, it's something that I've been familiar with for years, but not in any advanced way. My fingers don't dance over the keyboard like some Vim masters that I've worked with, but my muscle memory can usually get me to copy, paste, indent etc without having to Google how to do it.

I don't have anything against IDE's, I love the Lazarus IDE, for example, and IntelliJ IDEA is fantastic for Java. But I also occasionally have to write a Python script, or something in Laravel, and I don't like having to use a different IDE for each language. So I decided on using one text editor for everything so that I can just get familiar with one environment. I quite like Geany, but eventually went with Vim. It can be configured to do almost anything and I'd like to dedicate some time to using it exclusively so that I can become one of those Vim masters...

I'm currently using the following plugins in Vim

NerdTree
For navigating through a projects directory structure

NerdCommenter
To easily comment out blocks of code, the brute force way of finding a problem

ALE
This is a code linter and formatter. Although I haven't found any linters for Free Pascal, I've set it up to call ptop the source code formatter whenever I save a file. A quick :w will nicely arrange my code, although I don't like the way that it capitalised the first letter of each keyword (the code formatter in Lazarus is much better). Everything is formatted consistently though so I don't have to waste time prettying up my code.

lightline
A status bar that matches my colourscheme

Monokai theme
I use this on most text editors / IDE's that I have.

ctags
Not really a plugin, I generate tags for each project that I'm working on so that I can jump to a function when I'm browsing the code. Vim also uses the tags file for autocomplete.

I've also installed FP IDE, that's the old fashioned text based, Free Pascal IDE that's designed to look similar to Turbo Pascal.
I may end up not using this very often, but installed it mainly as a browser for the installed Free Pascal help files and language documentation. It also helps to organise my build profiles for debugging / release versions.
The fact that it has a built in ASCII table lookup tool also makes it perfect for roguelike development.

 

So I currently have a development machine that allows me to write, edit, compile and test my code without ever having to open a graphical desktop. It allows me to focus more on the code without any distractions.

If anyone has any suggestions, particularly for command line tools that help with development / code management, I'd love to hear them.

Roguelikes, a very strange hobby

Disclaimer. This post assumes some familiarity with the idea of roguelike games, if not with the games themselves. This isn't a 'history of roguelikes' post, for that see here

Recently I was working on a graphical roguelike that I occasionally dust off and tinker with, Axes, Armour & Ale. It uses graphics in a very loose sense of the word, just small static tiles with no animation. I was trying to add stairs to the caves and dungeons to allow the player to go deeper and deeper into the dungeon and realised that I needed to do a lot of refactoring.

The original game just took place in a single dungeon, a la Rogue / Nethack etc, but then I decided that I wanted an overworld map as well, like ADOM.

I started pulling out bits of the code and sticking it in other places and found that I was writing lots of simple test programs in pure ASCII to try out features before committing to drawing graphical assets. In the end, I decided to do something that I had in mind when I first started Axes, write a back-to-basics, 80x25 terminal-based roguelike. With the option of later creating a GUI version from the same codebase.

With the constraints of writing a game that worked in both the Windows and Linux terminal, I found that I gained a lot more enthusiasm for the project. This was more like the games that got me into roguelikes in the first place. When I first fired up Nethack in 2002 and discovered what it was like to play a game that didn't give a damn whether you lived or died. Then I moved onto ADOM and found a game with a more cohesive story that took itself a little more seriously.

I don't play games as often as I used to now that I have kids, but a turn-based roguelike is easy to pick up and put down between episodes of Paw Patrol and visits to the local playground.

Once I was confronted with the text version of my unfinished game, it struck me that writing roguelikes is a damn strange hobby. Eschewing graphics, sound or really any advances made in game theory over the last few decades, to craft a form of entertainment that owes more to table-top role playing games and Choose Your Own Adventure books than a regular computer game. I regularly read peoples posts on r/roguelikedev  and see the vastly different approaches that people have to this genre. My approach is closer to the classic roguelikes already mentioned above.

After 2 previous attempts at writing a roguelike by following a tutorial (one in Java, and one using the Godot game engine) I'm winging it this time, with no tutorials to refer to. I've set myself some limitations, after writing one game using OOP and one using ECS, this one will be purely functional programming. I also want a native binary that doesn't require any external libraries in order to run.

I've decided to write it in the awesome Free Pascal, whilst totally ignoring its object-oriented features. Now that I write code for fun rather than for a living, I don't have to force every type of program into an OOP structure.

At the moment I've only gotten as far as organising the user interface and the units that I'll use to write to the terminal, so it's slow going and there isn't much to show yet. But I already have a scrolling map that scrolls a lot smoother than the graphical version does.

It's all about the people

Back in the day, when I thought that I was going to change the world from behind a keyboard, I wrote a password manager application.

 It was a small, portable application that ran in both Windows and Linux, without needing to be installed. The idea was that you could keep your passwords with you on a USB stick and have access to them wherever you were.

The application also had the option to generate strong passwords for your online accounts and used 128 bit AES encryption to protect the whole thing.

The application was called LazLock and was marketed as a user friendly alternative to larger applications like KeePass, or less secure options like keeping your passwords in the cloud.

LazLock began to be used by a lot of people and was reviewed in Linux Format magazine in their 2018 round-up of open source password managers. I got a real kick out of having a print magazine doing an article on something I'd written, but then I experienced the flip-side of having written software that people actually used... the users.

I began to receive feature requests and tech support questions from people all over the world who were using LazLock.
I tried to answer them as quickly as I could, I still remember being stuck in a post office queue in Wrocław and guiding an elderly gentleman via email in how to backup his data.

I actually began to resent the amount of emails and DM's that I was receiving, it became a massive time-sink to respond to them all.

But just before I turned into a total Cyber-Scrooge, something happened.

I was contacted by another coder who asked if he could translate the software into Portuguese, his native language. After some back and forth, he took on the duties of running the translation team and LazLock is now available in 17 languages at the last count.
The elderly gentleman who I provided support for in a post office queue made a cash donation to the project and paid for the web hosting.

People have since forked the project, now it's grown beyond me and become its own thing. I couldn't be happier about that.
The community that has grown up around it has improved it more than I ever could on my own.

Too often in security, and cyber security in particular, we view people as the biggest point of failure. A vulnerability rather than a strength.

Without people though, security is a solution without a problem. It's all about the people