Self-hosting my website

Vikram Saran — Sat, 28 Feb 2026 00:00:00 +0000

Going my own way</h2>
For the past decade I've used this website for intermittent blogging</a>, updating my CV</a>, as a contact point for some consulting work</a>, but I don't spend a lot of time on it.
I love having a personal website, and I love that the blog posts I do have seem to help people (I still get dozens of daily hits on my various posts about AI/Navigation in UE4</a>). But I don't really spend all that much time blogging, and yet I have paid through the nose for services I barely use, which are bloated and slow, and I am steadily losing trust in.
So, although my day job is managing teams of game engine developers to make some really cool tech</a>, I decided to finally brush off my web-dev and sysadmin skills, apply my love of optimisation, and dive into the details of a tech stack I'm less familiar with.
This post is more of a diary entry, rather than a tutorial. I'm chronicling what I've done, as well as why and how I've done it. It should show how joining the "indie web" isn't all that difficult if you're a little tech savvy.
Bottom line up front?

Blog posts transfer 99% less data and load in 4% of the time</li>
Costs went from ~USD$450 to ~EUR€180 per year (>50% savings)</li>
More control over my data (tracking fewer things, in GDPR safe places)</li>
My "own" server I can tinker with</li> </ul>
And most importantly - I learned a lot - and I love learning!
Motivation</h2>
I had a perfectly working website, why would I go through the hassle of self hosting?
Firstly, I've been paying about $450 USD per year to Squarespace for a website (~$280), my domain name (~$80), and my google workspace (~$85). Both Squarespace and Google Workspace provide a plethora of features that I don't really need - I don't need a visual editor for blog posts I author in markdown anyway.
Secondly, my website's performance was abysmal.
</picture> </figure>
It transfers ~61.84 MB over 100 HTTP requests, and sometimes takes more than 10 seconds to finish fetching all network data. The "Load" Event takes nearly 2 seconds to occur.

An LLM tried to tell me that "In the world of web dev, 2 seconds for a load event isn't actually that bad" - maybe for a dynamic website, not a blog! </blockquote>
Thirdly, with the state of international politics right now, I wanted to bring my data under my own control - to try and achieve "digital sovereignty". My squarespace website had heaps of javascript frameworks, google analytics, and other things I find annoying as a user. I'd rather replace it with simple server-side stats, no cookies, and no third-party scripts.
Finally... I like tinkering. Having my own server to play around with is highly appealing to me. Well, technically I already have a couple of servers at home - but maintaining something that's "live" and used by other people is always a lot more interesting to me. I wanted to own my own web footprint. I wanted to see how it all fit together and ticked. I wanted to optimise, tinker, break it, and make it better.
So to flip those frustrations into goals (in no particular order):

Save a bit of money in my hosting</li>
Be "blazingly fast" 🔥🚀</li>
Use the modern web (e.g. HTML5 `<details></code>) rather than bloated JS frameworks</li>`
`Use IaC/DevOps best practices to enable the features I care about</li>`
`Simplicity and ease of use for myself</li>`
`The ability to add new things as I think of them</li> </ul>`a.k.a. cheap, fast, using best practices, standards compliant, maintainable, and extensible. All of the things a Technical Director tries to make a product. </blockquote> Tech Stack</h2> Static Site Generator</h3> This website is mostly a repository for blog posts, so using a static site generator to help with the markdown -> HTML step made sense. I don't need a full CMS. I know a lot of people are building their SSG, but for me - to start with - I picked one off the shelf. After a bit of research, I chose Zola</a>. I didn't spend a lot of time on this decision, something was better than nothing, and as long as it mostly worked out of the box, I could pick a template and write my own structures/CSS later. Considering I've heard that Hugo's templating engine is obtuse, I went with one I could eventually learn. I started with the anemone template</a>, but quickly forked it and replaced it with my own templates once I realised how trivial it was to do so (plus I could avoid using a git submodule!). I have a couple of little quality of life elements on my website that I wanted, and it was easy enough to use modern HTML, CSS, and a little bit of raw javascript to make them work (e.g. the floating Table of Contents). Zola shortcode template example</summary> I like accordions for details, and I use them thoroughly. On my old website I had some ugly javascript hacks to make them work nicely, but with modern HTML5 it's easy. You set up an accordion.html</code> template: <details {% if open %}open{% endif %} {% if name %}name="{{name}}" {% endif %}> <summary>{{ summary | markdown(inline=true) }}</summary> <div class="accordion-content">{{ body | markdown | safe }}</div> </details> </code></pre> Which lets me do this in my markdown: // Note: %'s replaced with & to avoid triggering the template engine {& accordion(summary="Zola template example") &} I like accordions for details, and I use them thoroughly. On my old website I had some ugly javascript hacks to make them work nicely, but with modern HTML5 it's easy. ... {& end &} </code></pre> </div> </details> On top of that, I was able to drop a bunch of weight in the data transfers by processing my images, sizing them properly (zola has a nice resize_image</code> function), and using webp</code> to reduce size further. Deployment</h3> I'm very comfortable with git and DevOps, I've worked in this area extensively, so it was natural for me to settle for GitLab to start off with. Eventually I want to set up gitea</code> and some non-yaml CI solution, but I haven't seen anything that calls to me yet, so I'll do this another day. For now, GitLab with my home N150 NUC as a runner is plenty. </blockquote> GitLab CI Setup</summary> My initial CI setup was quite simple. A docker job: variables: DOCKER_IMAGE : "$CI_REGISTRY/$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME" default: image: $DOCKER_IMAGE:latest docker: stage: docker image: docker:latest services: - docker:dind before_script: - echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin script: - docker build -t $DOCKER_IMAGE:latest . - docker push $DOCKER_IMAGE:latest rules: - if: $CI_PIPELINE_SOURCE == 'merge_request_event' changes: [Dockerfile] - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH </code></pre> A zola job: build-zola: stage: build cache: key: zola-media-cache paths: - static/processed_images script: - zola check - zola build artifacts: paths: - public rules: - if: $CI_PIPELINE_SOURCE == 'merge_request_event' - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH </code></pre> And a gitlab pages publish job: publish-website: stage: publish script: - ls -la public artifacts: paths: - public pages: true rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH </code></pre> I also hooked up rendercv</code> for automatically making pretty resume CVs, lychee</code> for link checking, and markdownlint</code> for completeness (also in pre-commit). </div> </details> Once I had the website working on gitlab pages, I spent a bit of time porting my old content over. Easy enough, because I already used markdown for authoring content. I didn't have to change too much, just switch from inline html to shortcodes and add some frontmatter. Fortunately, LLMs are pretty useful in this context. Hardware</h3> As much as I'd like to host from hardware at home, my ISP isn't that reliable, and I'd like to avoid pointing web traffic to my home network, so I'm renting a Hetzner VPS (CX23). This is a steal at €3 per month (and still okay even though it's just raised</a> to €4). As someone with not much infra/backend experience (especially public facing), I found their UI perfectly cromulent, and would recommend them whole heartedly. It's probably the smoothest hardware requisitioning system I've ever used. Server Infrastructure</h3> I'm moderately comfortable with nix systems, but I thought I'd try something I've been reading a lot about and would like to learn - NixOS</a>. If you've not heard of it, Nix is a package management tool (and programming language) which is declarative - the IaC dream. NixOS takes it a step further. It's a GNU/Linux distribution that manages its own configuration entirely through the Nix language. </blockquote> Although it took a bit of re-reading the docs, going through the "nix pills" (a tutorial for nix</a>), and some LLM support, I've come to be pretty comfortable with messing around with my setup. If you are comfortable with programming or scripting, I think it's worth the plunge. All of the following is done via .nix</code> config files: Setting up NixOS on a Hetzner VPS</summary> Don't try and use nixos-infect</code>, Hetzner has a great UI for loading various ISOs and booting from them, including a NixOS 25.04 image which I used to install the OS to the main drive and the MBR. I wish I could have used cloud-init</code></a>, but I didn't quite figure it out. And in order to reset your VPS and start with a new cloud-init</code> config, you need to delete it and spin up a new one - a bit too much of a hassle. </div> </details> The nicest thing here is I have a git repository set up for the /etc/nixos/</code> directory, so the entire server is trivial to reproduce in case of emergency. Web Server</h3> I wanted something super simple, and from what I could find online, Caddy</a> is the best in that respect. It's fast, memory efficient, automatically sets up HTTPS/TLS certificates, and integrates easily with NixOS. This was much much easier than my dim memories of struggling with apache/nginx, and extending it later on was also equally easy. Caddy in NixOS</summary> The following snippet is more or less all I needed to start with. services.caddy = { enable = true; virtualHosts."vikram.codes" = { extraConfig = '' root /var/www/vikram.codes file_server # Adding compression is as easy as encode zstd gzip # Technically this isn't quite right # But it's good enough for now - "respond to all errors with my 404 page" handle_errors { rewrite * /404.html file_server } ''; }; </code></pre> It's even easy to handle the constant stream of bots sniffing for vulnerabilities in WordPress setups: @killbots { path .php /wp- } respond @killbots "Access Denied" 403 </code></pre> Finally, I spent a bit of time scraping my old website/sitemap for urls I'd need to redirect, and dumped them into a block: services.caddy.virtualHosts."vikram.codes".extraConfig = lib.mkAfter '' redir /s/git-slides.pdf /blog/git-lfs-file-locking/git-slides.pdf permanent redir /s/spike-slides.pdf /blog/agile-spikes/spike-slides.pdf permanent # etc. '' </code></pre> </div> </details> Security</h3> I am certainly not an expert in security, but I have a couple of basics to help out. Of course, there are fundamentals (use a firewall, only open specific ports, don't allow password-based SSH login, etc.), but I went a little beyond those. Firstly, sops-nix</code></a> to manage secrets for me. Using sops-nix</summary> At about this time I needed to switch to using nix "flakes"</a>. It's marked experimental, but it seems like plenty of people encourage their use. inputs = { nixpkgs.url = "github:nixos/nixpkgs/nixos-25.11"; sops-nix.url = "github:Mic92/sops-nix"; sops-nix.inputs.nixpkgs.follows = "nixpkgs"; }; outputs = { self, nixpkgs, sops-nix, ... }@inputs: { # 'my-host-name' must match 'networking.hostName' nixosConfigurations.my-host-name = nixpkgs.lib.nixosSystem { specialArgs = { inherit inputs; }; modules = [ ./configuration.nix # This makes the sops.* options valid in configuration.nix sops-nix.nixosModules.sops ]; }; }; </code></pre> At this point the rebuild command changes slightly to nixos-rebuild switch --flake .</code> </div> </details> Secondly, fail2ban</code></a> to block bad actors. Fail2Ban Setup</summary> My fail2ban</code> set up is nothing fancy, but I'd like to think it's functional: services.fail2ban = { enable = true; bantime = "1h"; maxretry = 5; bantime-increment = { enable = true; formula = "ban.Time * math.exp(float(ban.Count+1)banFactor)/math.exp(1banFactor)"; # Exponential growth maxtime = "168h"; # 1 week overalljails = true; }; jails = { caddy-4xx.settings = { enabled = true; port = "http,https"; logpath = "/var/log/caddy/access-vikram.codes.log"; backend = "polling"; filter = "caddy-4xx"; findtime = "30m"; datepattern = ''"ts":(?P<timestamp>\d{10}\.\d+) ''; }; caddy-killbots.settings = { enabled = true; port = "http,https"; logpath = "/var/log/caddy/access-vikram.codes.log"; backend = "polling"; filter = "caddy-killbots"; findtime = "30m"; maxretry = 1; # Immediate bantime = "8760h"; # 1 year datepattern = ''"ts":(?P<timestamp>\d{10}\.\d+) ''; }; }; }; environment.etc."fail2ban/filter.d/caddy-4xx.conf".text = '' [Definition] failregex = ^."remote_ip":"<HOST>"."status":(404|403|401).$ ''; environment.etc."fail2ban/filter.d/caddy-killbots.conf".text = '' [Definition] failregex = ^."remote_ip":"<HOST>"."uri":"[^"](\.php|/wp-).$ ''; </code></pre> </div> </details> DNS and Monitoring</h3> Finally, when I migrated my DNS registration and records away from Squarespace, I made the decision to split them up. I use gandi</a> for registration, and deSEC</a> to host my records. Gandi is a bit more expensive than the US options, but not too much (~€100/year). Using deSEC made it trivial to update my DNS records inside my nix config using their API. If my IP changes for any reason, e.g. in the future I migrate to my own hardware, it's all handled automatically. Updating DNS records in NixOS</summary> systemd.services.update-dns = { script = '' set -euo pipefail TOKEN="$(cat ${config.sops.secrets.desec_token.path})" IP="$(${pkgs.curl}/bin/curl -fsS https://api.ipify.org)" [[ -z "$IP" ]] && echo "Could not fetch IP" && exit 1 PAYLOAD="$(${pkgs.jq}/bin/jq -n --arg ip "$IP" '[ { subname: "", type: "A", records: [$ip], ttl: 3600 } ]')" echo "Current IP: $IP" echo "DNS Payload: $PAYLOAD" ${pkgs.curl}/bin/curl -fsS -X PATCH \ https://desec.io/api/v1/domains/your.domain/rrsets/ \ -H "Authorization: Token $TOKEN" \ -H "Content-Type: application/json" \ -d "$PAYLOAD" '' </code></pre> </div> </details> Adding new subdomains is trivial from there. I've put some in for stats tracking using goaccess</code></a> and uptime monitoring with Gatus</code></a>. The Migration</h2> At this point I had everything ready to go. Parity with the website on gitlab pages. A server ready to host. A pipeline to get things from one to the other (I updated my gitlab-ci to rsync</code> to my VPS). To be honest, I might have muddled timelines and done some of the above later in the process - I'm writing this in retrospect. </blockquote> Publishing from GitLab CI</summary> deploy: stage: publish script: - rsync -avz --delete public/ $DEPLOY_USER@$DEPLOY_HOST:/var/www/vikram.codes/ </code></pre> </div> </details> I was expecting it to be a bit dramatic - some failures or outages... but it was pretty easy after all that setup. I got the transfer code from squarespace, waited a few days for my bank transfer to clear with gandi, moved my dns records to deSEC (but pointing at Squarespace to start with). Once I was ready, I uncommented my NixOS update-dns script section the root domain, ran nixos-rebuild switch --flake .</code>, and waited. A few minutes of watching my DNS updates roll out</a>, and that was it! The hardest part was the psychology - double and triple checking that I hadn't missed anything. </blockquote> Mail Server</h3> The last part I didn't talk about above is migrating my email from Google Workspaces to mailbox.org</a>. I don't use many workspace features, so this works well for me. Because I went with a hosted solution, there's not a lot of technical detail here. Mailbox has a good set of docs</a> about how to do it. The cut-over process is more or less the same (set up the new system, keep MX/SPF/DKIM records pointed at the old host, cut over when tested, test that it hits the new endpoint), but with a manual copy step using Thunderbird to transfer my mail history across (sadly, the automated migration tool didn't work for me). To ensure that your emails don't bounce, setting MX records along isn't good enough. Mailbox.org suggests setting SPF, DKIM, and DMARC</a> as well. Note: You can't just copy-paste the values from the mailbox docs for deSEC - you need to ensure the subname</code> is lowercase! </blockquote> Results</h2> My pages are close to 100 across the board in PageSpeed for the same post as before: </picture> </figure> I do have straight 100s for my home page, but that's much easier. </blockquote> I've dropped to under 500Kb total transfer, with it finishing in ~0.6s - and that's without bothering to have a CDN. I'm pretty sure I could improve it even further if I fixed up my fonts.css</code></a> and used variants, or dropped custom fonts altogether. Metric</th> Squarespace</th> NixOS + Zola</th></tr></thead> Total transfer</td> 61.8 MB</td> 663 KB</td></tr> HTTP Requests</td> 100</td> 12</td></tr> Load time</td> ~10s</td> <250ms</td></tr> PageSpeed Performance</td> 47</td> 97</td></tr> PageSpeed Accessibility</td> 81</td> 100</td></tr> </tbody></table> All local tests were with a cold cache, private browser window, same version of Firefox </blockquote> Everything that I care about is achieved: It's cheaper, by far ~€4pm for the VPS</li> ~€30pa for the mail server</li> ~€100pa for the domain</li> </ul> </li> It really is "blazingly fast" 🚀</li> Robust content pipelines</li> Greatly reduced digital footprint</li> I know the whole thing inside and out, so maintenance is easy</li> And I've already added a handful of services that I didn't bother with before</li> </ul> Next steps</h2> As with many self-hosting/homelab projects, I get a lot of enjoyment just from tinkering. So I'm going to keep doing that, adding new services (e.g. kanidm</code></a> for identity management, a subdomain to host my drafts behind OAuth login, etc.), and continuing to learn and grow. I have a few ideas on how I'd like to extend this, and I'm sure I'll come up with more: For now I'm happy to use mailbox.org, but eventually I'd like to consider hosting my own mailserver (CalDAV/CardDAV as well).</li> With Discord asking for ID globally</a> I'm interested in hosting my own XMPP server</a> (or something else</a>?).</li> I'm also looking at moving my (and my family's) personal data out of Google Photos and Dropbox and investigating Immich/Seafile.</li> </ul> Final thoughts</h2> Should you do this? Absolutely - if you're comfortable with learning the above, you don't need e-commerce or something dynamic, and want to bring back the early magic of the distributed web. Hopefully this blog post can help others try the same thing! There is some risk - I am my own SRE, I don't have a CDN, and if anything goes wrong I'm on the hook myself - but to me the tradeoff is worth it. I have everything I need to spin up my website on a new VPS in a matter of hours, if not minutes. Overall this took me maybe a week of effort spread over a couple of months - and I loved every part of doing it. The result, in my opinion, speaks for itself. As someone who cares about game engine performance, how can I not care about my website's performance too? If you want a peek at my git repositories, or have suggestions for improvements, please reach out via email</a>. Oh and if anyone reading this has a lobste.rs</a> account, I'd love an invite. Git LFS File Locking Vikram Saran — Fri, 22 Mar 2024 00:00:00 +0000 Introduction</h2> This article is an accompaniment to a presentation I gave at GDC 2024</a>. You can download the presentation slides</a>. </blockquote> Git lfs file locking</a> is a key feature for game development using modern git, although it is currently underutilised. A lockable file, in git terms, is a file which can only be edited by one person at a time - perfect for binary files, like art assets, and therefore an incredibly useful tool for game development. A majority of large game development studios use Perforce over git, despite the fact that, nowadays, git can scale</a>, and has the features to match Perforce, as well as a vibrant ecosystem of tooling. My presentation, and this guide, are an attempt to provide an alternative - to show game developers that git is perfectly capable of handling what you need. The below is primarily a guide for technical users, setting up and using git lfs file locks via command line, although there is a discussion in how to make this accessible for less-technical users in my presentation, as well as in the Making It Accessible</a> section below. LFS and File Locking</h2> Git lfs file locking has been introduced in mainline git since 2020 - although an early version was released in Git 2.0.0 in 2016. Git lfs has has been described in a range of places</a> online, so I won't re-iterate here. But as a short summary: a file which is managed by git lfs (Large File System) is actually stored as a "pointer", which is then de-referenced ("smudged") when you need the actual file contents. This happens automatically with all modern git clients. In the past, it was common to run into issues and needing Git lfs file locking, despite its name, does not require that a given file be marked as an lfs file in order to lock it, although interacting with the file locking mechanism is done through the git lfs</code> subcommand. How locking works</h2> A lockable file is read-only by default, and in order to edit the file you must ask the server if you can acquire the "lock". Only one person can acquire a lock, per file, at a time. If a second person requests the lock, the request will be rejected unless the first person has unlocked the file. Naturally, commands interacting with the locking mechanism must typically query a server. All modern git hosts support both lfs and file locking. One important caveat: lockable files in git are locked across all branches, as they are locked by filepath only. This is in contrast with Perforce, where files can be locked per branch. Setting up</h2> Files which you want to be lockable need to be marked as such in your .gitattributes</code> file. You can do so manually, by editing the file to add the lockable</code> attribute to any relevant filetypes: .psd filter=lfs diff=lfs merge=lfs -text lockable shared sharedtextfile.txt lockable </code></pre> Note: You don't need to mark a file as lfs</code> in order to give it the lockable attribute! </blockquote> Or via the command line: git lfs track --lockable ".psd" git lfs track --lockable --filename "sharedtextfile.txt" </code></pre> Note: the last command will actually mark the "sharedtextfile.txt" as both lfs and lockable - if you want to create a non-lfs lockable file, you will need to do so manually. </blockquote> You can set the attribute for any set of files using any regex pattern - meaning this can apply to swathes of files by type, by folder structure, or by any other pattern. The 3 daily commands</h2> There are three important commands for git: git lfs locks</code> - to see which locks are held</li> git lfs lock <file></code> - to try and acquire a lock</li> git lfs unlock <file></code> - to release a lock</li> </ul> You can investigate these commands and their options by using --help</code>, like all git commands. git lfs locks</code></summary> This command is lists all of the currently locked files by all users. You can optionally pass in a path --path=<path></code> in order to check who owns a specific lock. Another helpful option is --local</code>, which lists only your own locks which are cached locally. This can be done offline without a call to the server. </div> </details> git lfs lock <file></code></summary> This command is as simple as it gets. You ask the server to "lock" the given file to your user. This blocks attempts by other users to lock or edit the file themselves, until the lock is released. </div> </details> git lfs unlock <file></code></summary> Equally simple, this command lets the server know that you are done with the lock, and which to relinquish it. If you have sufficient permissions, you can --force</code> the server to unlock a file held by another user. This should be used sparingly, but can be useful if, for example, someone is off on leave and forgot to unlock a file! </div> </details> Bonus Options</summary> As of git lfs 3.0, both lock and unlock support submitting multiple files. Additionally, there is a HTTP based API</a> if you want to integrate lock or unlock commands into a tool that you are building, and want to avoid command line calls to the git executable. </div> </details> Switching to Rebase</h2> Because git file locking works on file paths, and locks the file across all branches, this means that we are unfortunately unable to git merge</code> a locked file. Naturally, this can cause some problems! If you need to update a feature branch or release branch (the target) but the branch you are trying to update from (the origin) has a change to a file which someone holds a lock for... well... you are then unable to lock the file, and therefore unable to use git merge</code> to update your branch. Note: this is because of the way that git merge works. The merge commit created includes all of the changes that the origin branch has received since the target branch was last updated in this way. </blockquote> Fortunately, git has rebase</code> in order to do what you need. Instead of merging the updated state of the origin branch into your target branch, you reapply your target branch on top of the origin. Rebase has been sufficiently explained</a> elsewhere, and a multitude of git experts have explained the other benefits</a> of switching to rebase</a>, so we can move on. Trunk Based Development and DevOps</h2> One thing that you get, as a side effect of using a rebase-centric workflow, is easier access to being able to achieve trunk based development</a>, which is one of the key technical capabilities of world class devops</a>. Making It Accessible</h2> One tricky problem in game development is users who don't want or need to know about their version control internals, yet need to be able to work with it - your designers and artists. For file locking, I would generally recommend that all lockable files have an integration in their DCC (Digital Content Creation) tool of choice, whether it's a game engine or anything else. However, in general, less-technical users will want a GUI method to interact with git. Whatever method you select should include a way to run the above git lfs file locking commands. To date, I believe the best in this area is git-fork</a>, although I have also had success with TortoiseGit</a>. One interesting option is AnchorPoint</a>, although note that it does not use git's implementation of file locking, but rather its own system. In order to ensure that rebases are trivial, there are a few simple tricks: Reduce the number of required rebases</li> Reuse your team's expertise in git through good visual documentation and live support</li> Recycle whatever rebases are still required by using automation</li> </ol> It's actually just reduce how many user-initiated rebases are needed. but I really wanted to do the 3 R's </blockquote> All of the above are described in greater detail in my presentation</a>. References</summary> Most searchers for git lfs file locking stumble upon the proposal docs rather than the final docs, so part of this guide's purpose is to improve the SEO of the actual documentation pages (linked throughout, and below). git lfs track</a></li> git lfs locks</a></li> git lfs lock</a></li> git lfs unlock</a></li> </ul> </div> </details> Agile Spikes Vikram Saran — Fri, 15 Mar 2024 00:00:00 +0000 Introduction</h2> This article is a companion to my talk at GDC 2024, "Agile Spikes in Game Dev: Getting to the Point"</a>. You can download the presentation slides</a>. </blockquote> The meat of this article is presented in the two attached templates. If you download them and try them out, please email me</a>! Word doc</a></li> Markdown</a></li> </ul> Alternatively, you can try Microsoft's much lighter template</a> but if you don't have much experience with Spikes it might be safer to start with the guard rails on. The following is a very brief overview of what an Agile Spike is, and some links to further reading. There is a lot more information in the GDC talk (linked above). What is a Spike?</h2> As is the recent trend, I asked ChatGPT (instead of a dictionary) to provide a definition for what is an Agile Spike: An Agile spike, often referred to simply as a "spike," is a time-boxed research or investigative activity conducted by Agile teams to gather information, answer a specific question, or mitigate a risk. It is a technique commonly used in Agile software development methodologies like Scrum or Extreme Programming (XP). </blockquote> Not bad, ChatGPT! My own definition is this: A spike is a short, reproducible, exploratory task to gain the knowledge you need to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate. </blockquote> The key difference between mine and most other definitions is "reproducible". I find that it helps improve the quality of the spike reports, and help build a knowledge base that is more useful in a longer term. Hopefully, the links below, the templates, and the above definitions help you all out with figuring out how to apply this to your own projects - and if all else fails, reach out, I'm always happy to answer questions. References</summary> Extreme Programming</a></li> WikiWikiWeb</a></li> SaFE</a></li> Microsoft</a></li> Agile Development Spikes Applied to Computer Science Education, Woodward et al.</a></li> </ul> </div> </details> Navigation Filtering and Avoidance - Basic Tag AI in UE4 Vikram Saran — Sun, 18 Mar 2018 00:00:00 +0000 Introduction</h2> In the last couple</a> of posts</a>, we've explored some of the abilities of the UE4 Navigation System. In this post, we're going to look at setting up some rudimentary AI logic using Blueprints/C++. We're still going to touch on some Navigation concepts however, specifically, Filtering and Avoidance. By the end of the today, you're going to have a fully functioning AI vs AI "Game of Tag"! Specifically, we're going to add: A "tagged" status, to indicate if our AI is "it" or "not-it". When the "tagged" status is changed, we're going to change: The colour of the mesh</li> The maximum walking speed "it" bots can move slightly faster</li> </ul> </li> </ul> </li> Depending upon being "tagged", the AI will behave differently: "it" bots will move towards the nearest "not-it" bot that it can see, or a random spot on the map if it can't see</li> "not-it" bots will simply run to random points on the map but we'll bias this to try and run away from any visible "it" bots!</li> we'll also turn on Avoidance for them, so they try and avoid being touched by the "it" bots, even when passing close by!</li> </ul> </li> </ul> </li> We'll make it work with a little gameplay - an "it" bot can "touch" a "not-it" bot to make it "it".</li> </ul> Note: this variant of tag is sometimes known as "zombie tag" </blockquote> Finally, we're going to use some Navigation Filtering to change whether the bot can use the Launchpads, so that "it" bots can't use them - giving the "not-it" bots a chance to get away!</li> </ul> A lot of this, if not all of this, will be replaced in later stages (using the UE4 Behaviour Tree, Environmental Query System, and Perception System), but it's useful to have a simple baseline script to compare against. The project has been updated to use version 4.18. This change required no adjustments to the code that we've written so far. </blockquote> If you haven't followed along, or just want to make sure you're on the same page, you can download the current state of the project</a> from the GitLab repository</a>. </blockquote> Apologies for the delay between posts - but hopefully you all enjoy this one! Due to the time taken to get this ready for publication, 4.19 has just been released! There appear to be no issues with using 4.19</a> at this stage, and the next post will be released using 4.19. </blockquote> AI Character: Tagged Status</h2> The first thing we need to do is add a "Tagged" status to the Character. We do this on the Character class because it is game logic, not input logic. We're also going to make this a visible change, so in a new ChangeTaggedStatus</code> function we're going to make this set the material of the character. We're also going to add two collision volumes that we can use later. One will be for "it" bots to tag a new bot, and the other will be for the AI's "vision radius". Before we start scripting, we'll need to create two Material Instances of the Mannequin Body Material found at TemplateContent/Mannequin/Character/Materials/M_UE4Man_Body</code>. </picture> </figure> You can then pick any two colours that you want to use for "it" and "not-it" bots. I chose Red and Blue: </picture> </figure> Tip: If you want to learn more about Material Instances, the Documentation</a> is a great resource! </blockquote> Blueprint: Tagged Status</summary> Although we could use an Enum</a> to indicate the status of our bot, because we are either "tagged" or not, we're just going to create a single public Boolean variable Tagged</code> on our Character class: If we had more than two states, we would use an enum (and the rest of the tutorial would continue the same). </blockquote> </picture> </figure> We're now going to create a function, ChangeTaggedStatus</code>, which will allow us to use this. This function is going to do more than just set the value of our variable, it's going to also set the material on our mesh and change our maximum walking speed: </picture> </figure> Note: You could easily replace the 'magic' numbers 660.f</code> and 600.f</code> with variables that the designers could tweak in the editor. </blockquote> We also want to be able to set our Tagged status in the editor, so lets call this function in the construction script: </picture> </figure> Now we have a functioning "tag" in our game logic! </figure> Before we continue, lets add two collision volumes. One is our "interaction" volume (where an "it" bot can touch a "not-it" bot), and the other is our "vision" volume: </picture> </figure> Note: The reason we use a Vision volume, is because we want to ray-trace against every known possible enemy. This is fairly cheap with a Collider, because they update their contained actors automatically as we move, but if we were to use (for example) Get All Actors of Class</code> to find all possible enemies, it would be very expensive! Later in this series we'll use the built in Unreal Engine systems to handle this for us. </blockquote> </div> </details> C++: Tagged Status</summary> There are a couple of small things to note when doing this in C++. Firstly, if you've downloaded a copy of the project at the top of this blog, you'll notice that there are two characters. We will be using the one with the _cpp</code> suffix (that does not contain any BP logic). Halfway through the development of this post, I moved this into a cpp</code> folder, and split up the level files into (BP/cpp/Geo). If you're following just C++, you shouldn't have an issue. </blockquote> Secondly, our Controller is in C++, and you can't utilise blueprint functions from C++ without a little bit of messing around! The main reason we want the BP character, anyway, is because it's easier to set Meshes and Collision sizes there, etc. So for this section, we're going to: Create a new ATagCharacter</code> class</li> </ol> Derived from the ACharacter</code> class</li> Add the variables, functions, and components which we might want to utilise in C++</li> </ul> Reparent the Blueprint class from the Character</code> class to TagCharacter</code> class in the Class Settings panel</li> Set the dimensions of our collision volumes in the child BP_TagCharacter_cpp</code> class!</li> </ol> Once you create the ATagCharacter</code> class, it'll have a load of cruft in there that we don't need. You can empty out the class declaration and lets fill it in with: UCLASS() class TAG_API ATagCharacter : public ACharacter { GENERATED_BODY() public: ATagCharacter(); // Denotes the area that an "it" bot can "tag" UPROPERTY(VisibleAnywhere) UShapeComponent InteractionVolume; // Denotes the area a bot can see UPROPERTY(VisibleAnywhere) UShapeComponent VisionVolume; // Whether the bot is "it" or "not-it" // Do not edit directly in any code (use ChangeTaggedStatus) UPROPERTY(EditAnywhere, BlueprintReadOnly) bool Tagged; // Sets the correct material and speed when changing Tag status UFUNCTION(BlueprintCallable) void ChangeTaggedStatus(bool NewStatus); // Call ChangeTaggedStatus if required void OnConstruction(const FTransform& Transform) override; private: // Using static material interfaces, // we can ensure we only load each material once static UMaterialInterface RedMaterial; static UMaterialInterface BlueMaterial; }; </code></pre> With just the above, you can probably fill in the implementation yourself! There's nothing particularly novel that we're doing. Let's go over each function, however. Firstly, the constructor. All we have to do is create our two components (I chose a Box and a Sphere as my shapes of choice) and load our materials into the static member variables: // By default, the materials are null UMaterialInterface ATagCharacter::RedMaterial = nullptr; UMaterialInterface ATagCharacter::BlueMaterial = nullptr; ATagCharacter::ATagCharacter() { // We are not going to use on tick logic in our character if we can avoid it PrimaryActorTick.bCanEverTick = false; // Build default shapes for our volumes InteractionVolume = CreateDefaultSubobject<UBoxComponent>(TEXT("Interaction Volume")); InteractionVolume->AttachToComponent(RootComponent); VisionVolume = CreateDefaultSubobject<USphereComponent>(TEXT("Vision Volume")); VisionVolume->AttachToComponent(RootComponent); // If the static material hasn't been loaded yet if (BlueMaterial == nullptr) { // Load the Material from our Content folder auto BlueMaterialLoader = ConstructorHelpers::FObjectFinderOptional<UMaterialInterface>( TEXT("/Game/TemplateContent/Mannequin/Character/Materials/MI_Body_Blue")); if (BlueMaterialLoader.Succeeded()) { BlueMaterial = BlueMaterialLoader.Get(); } } // If the static material hasn't been loaded yet if (RedMaterial == nullptr) { // Load the Material from our Content folder auto RedMaterialLoader = ConstructorHelpers::FObjectFinderOptional<UMaterialInterface>( TEXT("/Game/TemplateContent/Mannequin/Character/Materials/MI_Body_Red")); if (RedMaterialLoader.Succeeded()) { RedMaterial = RedMaterialLoader.Get(); } } } </code></pre> Note: If you make a mistake with the Constructor Helper calls, it may cause your project to crash upon opening. It's easy enough to open the code file and comment it out. Just be careful with the line and you should be ok! Consider yourselves warned. </blockquote> Next, the OnConstruction</code> function simply calls ChangeTaggedStatus</code> (as described in the header). void ATagCharacter::OnConstruction(const FTransform & Transform) { Super::OnConstruction(Transform); ChangeTaggedStatus(Tagged); } </code></pre> Finally, the ChangeTaggedStatus</code> function does three things. Sets Tagged</code> to argument passed in, and then based on the value, SetMaterial</code> on the Mesh</code> and the set the value of MaxWalkSpeed</code> on the CharacterMovementComponent</code>. void ATagCharacter::ChangeTaggedStatus(bool NewStatus) { Tagged = NewStatus; // Select the correct material using the Ternary operator auto Material = Tagged ? RedMaterial : BlueMaterial; // If we have a mesh auto Mesh = GetMesh(); if (Mesh) { // Apply the material Mesh->SetMaterial(0, Material); } // Select the Walk Speed using the Ternary operator auto MaxWalkSpeed = Tagged ? 660.f : 600.f; // Apply the walk speed GetCharacterMovement()->MaxWalkSpeed = MaxWalkSpeed; } </code></pre> Now that we've made our base Character class in C++, lets change the Parent Class</code> of our BP_TagCharacter_cpp</code>. We can do this in the Class Settings panel: </picture> </figure> </picture> </figure> Once you've done that, you can edit the settings of the Interaction and Vision Volumes so that they fit exactly where you want them to: </picture> </figure> Tip: This is one of the best ways to work with C++ and BP in Unreal. Using C++ to drive your core game logic, and using the BP visual editor to help select and place your Meshes/Materials/etc. </blockquote> Note: You could easily replace the 'magic' numbers 660.f</code> and 600.f</code> with UPROPERTYs that the designers could tweak in the editor. </blockquote> </div> </details> Fixing the Launchpad</h2> At this point, you may notice that your AI starts having weird interactions with any Launchpads around the level - this is because the extra volumes we've created are triggering the Launchpad! We're going to have to make a couple of fixes. Blueprint: Fixing the Launchpad</summary> Firstly, before we trigger the launch, lets check that the Other Comp</code> was the Root Component</code> of the Other Actor</code>. This means the launch will only trigger when we touch the Launchpad with our main collider: </picture> </figure> Secondly, we'll need to change the Calculate Launch Velocity</code> function we wrote to use the bounds of the root component, instead of the actor, when calculating our Start</code> location for the Launch: </picture> </figure> And now the Launchpads should work properly again! </div> </details> C++: Fixing the Launchpad</summary> Firstly, before we trigger the launch, lets check that the OtherComp</code> was the Root Component</code> of the Other</code> Actor. This means the launch will only trigger when we touch the Launchpad with our main collider. To do so, change the line in OnTriggerBeginOverlap</code> from: if (Character) </code></pre> To: if (Character && OtherComp == Character->GetRootComponent()) </code></pre> Secondly, we'll need to change the CalculateLaunchVelocity</code> function we wrote to use the bounds of the root component, instead of the actor, when calculating our Start</code> location for the Launch. This will be easier if we change the function's AActor LaunchedActor</code> parameter to ACharacter* LaunchedActor</code> (as we have already cast the Character, this should work easily). Then, the line that was: Start.Z -= LaunchedActor->GetSimpleCollisionHalfHeight(); </code></pre> Becomes: Start.Z -= LaunchedCharacter->GetCapsuleComponent()->GetScaledCapsuleHalfHeight(); </code></pre> And now the Launchpads should work properly again! </div> </details> AI Controller: Movement Behaviour</h2> Now that we have our status, we're going to tweak our Controller to take notice of this. Firstly, we're going to need a way for our AI to "see" other bots! Then, if we're "it", we'll move straight towards them! If we're "not-it", we're just going to move to a random point. However, if we can see some "it" bots, we're going bias our search for our random point away from any visible "its". Blueprint: Movement Behaviour</summary> To let our AI "see" the other bots inside the vision sphere, lets make a new pure function inside our BP_TagCharacter</code> - GetVisibleEnemies</code>. This function is going to get all of the AI Characters that are inside the volume, filter by "Tagged" status, and then ray-cast to them to ensure we can see them. The initial part of the function looks like this: </picture> </figure> The raycast is a little tricky. What we want to do is raycast from the eyes of our AI, towards the centre of the possibly visible enemy. If the first object we touch is the enemy, then we know we have a direct "line of sight"! To do this, we're going to write a new pure function, CanSeeTarget</code>: </picture> </figure> Note: Pay attention to the argument of the Trace Channel parameter - we change from Visibility</code> to Camera</code>, because Characters don't block Visibility by default! </blockquote> Note: By default, Base Eye Height is 64, but we should set it to be 72 for the default mannequin. This can be set on the character, under the Camera</code> heading. </blockquote> Note: If you wanted to be a bit more accurate, you could raycast from the eyes to the feet, centre, and head, and if any of the three raycasts succeeds you can see the target. But that may be overkill! </blockquote> Hook up the new function in the comment we left earlier, and it should end up looking like this: </picture> </figure> Now that the Character has its gameplay logic hooked up, we can head over to the Controller and start changing how our AI thinks. The first thing we need to do is store a reference to our Controlled Pawn which has been Cast correctly, because we need to start using the values (like Tagged</code>) that we're adding to the BP_TagCharacter</code> class. We're also going to replace calls of Go To Random Waypoint</code> with Movement Behaviour</code>. </picture> </figure> Note: We have to call Movement Behaviour after we store our Tag Character. </blockquote> Movement Behaviour</code> is a really simply function which abstracts away how we're handling our movement: </picture> </figure> In our It Behaviour</code> function, we want to either Move to Actor</code> on the first any we can see, if we can see any. Otherwise, we'll Go To Random Waypoint</code>: </picture> </figure> Tip: You can make the behaviour a bit more deterministic (and smarter) by making it move towards the nearest target, rather than the 0th target in the array. </blockquote> In our Not-it Behaviour</code> function, we're going to use similar logic. However, if enemies are around, we're going to generate three random waypoints, and pick the one that is the best option. We'll do this logic in a new pure function Find Flee Target</code>. </picture> </figure> By the time we get into the function, we are guaranteed to have at least one enemy. To bias our waypoint target away from all enemies, we're going to generate three Random Waypoint</code>s and then we'll find the one that is the furthest away from all enemies. Note: At this point, I usually prefer to write the code in C++, as it can get quite messy in BP, but it's perfectly viable. </blockquote> The first thing we need to do inside the Find Flee Target</code> is set up some local variables: </picture> </figure> Note: Local variables are accessible only during the function call, and will be set to their default values every time the function is called (i.e. they don't carry over information). </blockquote> </picture> </figure> Next, we're going to loop through each of the Waypoints that we generated, and figure out which is the furthest away from all the visible enemies: </picture> </figure> Now if you drop in two AI characters, one who's Tagged</code> by default, you should see them start chasing each other around! </div> </details> C++: Movement Behaviour</summary> Firstly, lets add a couple of functions to our TagCharacter</code>: public: UFUNCTION(BlueprintCallable) const TArray<ATagCharacter> GetVisibleEnemies() const; UFUNCTION(BlueprintPure) bool CanSeeEnemy(ATagCharacter Target) const; </code></pre> The code for these is rather simple: const TArray<ATagCharacter> ATagCharacter::GetVisibleEnemies() const { static TArray<AActor> VisibleCharacters; VisionVolume->GetOverlappingActors(VisibleCharacters, ATagCharacter::StaticClass()); TArray<ATagCharacter> VisibleEnemies; for (auto Character : VisibleCharacters) { if (Character == this) continue; auto TagCharacter = Cast<ATagCharacter>(Character); // If they don't have the same tag as me, and I can see them if (TagCharacter->Tagged != Tagged && CanSeeEnemy(TagCharacter)) { VisibleEnemies.Add(TagCharacter); } } return VisibleEnemies; } </code></pre> Note: We use function-local static initialization</a> to prevent us from creating TArray</code>'s for VisibleCharacters</code> with every call to this function. It might be an unecessary optimisation at this point - but this kind of thinking early on can help you scale your code! We don't do this for the second array, because we can rely on Return Value Optimisation</a> to take care of the optimisation for that. </blockquote> bool ATagCharacter::CanSeeEnemy(ATagCharacter Target) const { // Raycast from my eyes FVector RayOrigin{ GetCapsuleComponent()->Bounds.Origin }; RayOrigin.Z += BaseEyeHeight; // To the middle of their body FVector RayTarget{ Target->GetCapsuleComponent()->Bounds.Origin }; static FHitResult HitResult(ForceInit); FCollisionQueryParams params; params.AddIgnoredActor(this); GetWorld()->LineTraceSingleByChannel(HitResult, RayOrigin, RayTarget, ECC_Camera, params); return HitResult.Actor == Target; } </code></pre> Note: We use the same static initialisation for the HitResult. Using "magic statics" is ideal in situations where you will be creating a large data structure (>32 bytes) frequently, but do not need it to remain useful for a long period of time. This does mean, however, that you can not truly multithread such code</a>. </blockquote> Note: Alternatively, you can use a private member variable to achieve the same effect. However, this increases the size of your TagCharacter</code> per instance, and any function utilising that cannot be const</code> (without using the mutable</code></a> type specifier). </blockquote> Pay attention to the argument of the Trace Channel parameter - we change from Visibility</code> to Camera</code>, because Characters don't block Visibility by default! By default, Base Eye Height is 64, but we should set it to be 72 for the default mannequin. This can be set on the character, under the Camera</code> heading, or in the constructor. Note: If you wanted to be a bit more accurate, you could raycast from the eyes to the feet, centre, and head, and if any of the three raycasts succeeds you can see the target. But that may be overkill! </blockquote> Now that the Character has its gameplay logic hooked up, we can head over to the Controller and start changing how our AI thinks. Let's define the following: UFUNCTION() void MovementBehaviour(); UFUNCTION() AActor* FindFleeTarget(const TArray<ATagCharacter> Enemies) const; UPROPERTY() ATagCharacter TagCharacter; </code></pre> First, lets replace all existing uses of GoToRandomWaypoint</code> to use MovementBehaviour</code> instead, and store a pre-cast reference to our TagCharacter</code>: void ATagController::BeginPlay() { Super::BeginPlay(); UGameplayStatics::GetAllActorsOfClass(this, ATargetPoint::StaticClass(), Waypoints); TagCharacter = Cast<ATagCharacter>(GetCharacter()); if (TagCharacter) { TagCharacter->LandedDelegate.AddUniqueDynamic(this, &ATagController::OnLanded); TagCharacter->MovementModeChangedDelegate.AddUniqueDynamic(this, &ATagController::OnMovementModeChanged); MovementBehaviour(); } } void ATagController::OnMoveCompleted(FAIRequestID RequestID, const FPathFollowingResult & Result) { Super::OnMoveCompleted(RequestID, Result); GetWorldTimerManager().SetTimer(TimerHandle, this, &ATagController::MovementBehaviour, 1.0f, false); } </code></pre> Next, lets write our MovementBehaviour</code> function: void ATagController::MovementBehaviour() { const auto VisibleEnemies = TagCharacter->GetVisibleEnemies(); if (VisibleEnemies.Num() == 0) { GoToRandomWaypoint(); return; } if (TagCharacter->Tagged) { MoveToActor(VisibleEnemies[0]); } else { MoveToActor(FindFleeTarget(VisibleEnemies)); } } </code></pre> Finally, lets write the FindFleeTarget</code> function. By the time we get into the function, we are guaranteed to have at least one enemy. To bias our waypoint target away from all enemies, we're going to generate three Random Waypoint</code>s and then we'll find the one that is the furthest away from all enemies. Once we generate the waypoints, lets Algo::Sort</code></a> them by distance to the ActorArrayAverageLocation</code></a> for the enemies: AActor* ATagController::FindFleeTarget(const TArray<ATagCharacter> Enemies) const { const FVector EnemyAverageLocation = UGameplayStatics::GetActorArrayAverageLocation(static_cast<TArray<AActor>>(Enemies)); TArray<AActor> FleePoints = { GetRandomWaypoint(), GetRandomWaypoint(), GetRandomWaypoint() }; // Sort by the greatest distance to the enemy average location Algo::Sort(FleePoints, [&](const AActor A, const AActor B) { return FVector::DistSquared(A->GetActorLocation(), EnemyAverageLocation) > FVector::DistSquared(B->GetActorLocation(), EnemyAverageLocation); }); return FleePoints[0]; } </code></pre> Note: I had to add const</code> to GetRandomWaypoint</code> - which should have been marked as such from the beginning! </blockquote> Note: We use DistSquared</code> for our distance check, because we don't care about the exact distance, but only the relative distance from each waypoint. Using the Squared</code> version allows us to avoid an expensive sqrt</code> operation</a>. </blockquote> Note: The funny-looking second parameter to Algo::Sort</code> is a lambda</a>. You can think of it as an unnamed function which: "captures" ([&]</code>) all local variables (by reference), accepts two const AActor</code> as parameters, and has a function body with automatic return type deduction. </blockquote> Note: We return true if A should be earlier in the order than B, so we return true if A's distance to the enemies greater than B's distance to the enemies, and then return the first result. </blockquote> Now if you drop in two AI characters, one who's Tagged</code> by default, you should see them start chasing each other around! </div> </details> Gameplay: Tagging Behaviour</h2> Now lets add "tagging" when the "it" bot gets close enough to its target. For the Character, we want to add a couple of bits of game logic: When we are "it" and a "not-it" Character is in range, "tag" the target</li> When we are tagged, update our behaviour</li> </ul> If we wanted to, we could also make this a little more "interactive", by raising an event in the Character, and having the Controller decide whether or not to "tag" the target. This would allow, for example, a small grace period if an AI bot were to catch a player bot - creating much more user-friendly gameplay. However, as we are just making a purely AI-vs-AI demo, we're going to code everything to happen immediately. Blueprint: Tagging Behaviour</summary> Firstly, when the Character can touch something (Interaction Component Begin Overlap), and that thing is another player (BP_TagCharacter), and we are "it", and they are "not-it" - we will "tag" them! </picture> </figure> Secondly, when we ChangeTaggedStatus</code> (and we are actively in game, because we have a controller), lets stop movement, so that we immediately find a new place to move to (or other bot to run towards)! </picture> </figure> However, if you start running the game, you'll notice that your bots are getting tagged very early! This is because our Interaction Component is triggering the overlap event with the target's Vision Component! We want our Interaction Component to Ignore anything that's not a Pawn (which the Mesh and Capsule components are marked as) - so let's set up some Custom Collision: </picture> </figure> At this point, depending on how your waypoints are set up, you might get the "it" bot running blindly past a potential target on its way to its waypoint. There are a few ways you can fix this, but I'll leave this as an excercise for the reader. Here are some ideas to get you started: On Controller Tick (but make Tick Interval 0.5s or higher): If we are moving towards a waypoint</li> But Get Visible Enemies</code> returns something</li> Call Movement Behaviour</code></li> </ul> </li> On Character Vision Volume Begin Overlap If the other actor is an enemy Tag Character</li> And we Can See Target</code></li> Call an event dispatcher (New Target Seen</code>)</li> In the Controller: Call Movement Behaviour</code> when the Character's New Target Seen</code> event fires</li> </ul> </li> </ul> </li> </ul> Note: Both of these methods should improve behaviour for both "it" and "not-it" bots! However, they both have pros and cons - the first might be a little bit more responsive (depending on how you tune the Tick Interval) - but it means all of our bots use the Tick event, which is slow. We'll eventually replace this with the built-in Unreal Engine Perception System</a> and get the best of both worlds! </blockquote> </div> </details> C++: Tagging Behaviour</summary> Firstly, when the Character can touch something (Interaction Component Begin Overlap), and that thing is another player (TagCharacter), and we are "it", and they are "not-it" - we will "tag" them! We'll have to define a function, as well as add it as a delegate (just like we did with the Controller before): // TagCharacter.h - ATagCharacter UFUNCTION(BlueprintCallable) void OnInteractionEnter(class UPrimitiveComponent* OverlappedComp, class AActor* OtherActor, class UPrimitiveComponent* OtherComp, int32 OtherBodyIndex, bool bFromSweep, const FHitResult& SweepResult); </code></pre> // TagCharacter.cpp - ATagCharacter::ATagCharacter() InteractionVolume->OnComponentBeginOverlap.AddUniqueDynamic(this, &ATagCharacter::OnInteractionEnter); </code></pre> Then we'll implement the function as: void ATagCharacter::OnInteractionEnter(UPrimitiveComponent * OverlappedComp, AActor * OtherActor, UPrimitiveComponent * OtherComp, int32 OtherBodyIndex, bool bFromSweep, const FHitResult & SweepResult) { auto Target = Cast<ATagCharacter>(OtherActor); if (Target) { if (Tagged && !Target->Tagged) { Target->ChangeTaggedStatus(true); } } } </code></pre> Secondly, when we ChangeTaggedStatus</code> (and we are actively in game, because we have a controller), lets stop movement, so that we immediately find a new place to move to (or other bot to run towards)! // TagCharacter.cpp - ATagCharacter::ChangeTaggedStatus() // If we're in-game, stop moving! auto AIController = Cast<AAIController>(GetController()); if (AIController) { AIController->StopMovement(); } </code></pre> Note: We cast to AAIController</code></a> instead of ATagController</code> to avoid circular references</a> and having to forward declare</a> anything. This means that, unlike the blueprint version where new behaviour is immediate, C++ TagCharacters will pause when touched. You can likely figure out a way to work around this if it bothers you! ;) </blockquote> However, if you start running the game, you'll notice that your bots are getting tagged very early! This is because our Interaction Component is triggering the overlap event with the target's Vision Component! We want our Interaction Component to Ignore anything that's not a Pawn (which the Mesh and Capsule components are marked as) - so let's set up some Custom Collision: // TagCharacter.cpp - ATagCharacter::ATagCharacter() FCollisionResponseContainer InteractionResponse{ ECR_Ignore }; InteractionResponse.SetResponse(ECC_Pawn, ECR_Overlap); InteractionVolume->SetCollisionResponseToChannels(InteractionResponse); </code></pre> At this point, depending on how your waypoints are set up, you might get the "it" bot running blindly past a potential target on its way to its waypoint. There are a few ways you can fix this, but I'll leave this as an excercise for the reader. Here are some ideas to get you started: On Controller Tick (but make Tick Interval 0.5s or higher): If we are moving towards a waypoint</li> But GetVisibleEnemies</code> returns something</li> Call MovementBehaviour</code></li> </ul> </li> On Character Vision Volume Begin Overlap If the other actor is an enemy Tag Character</li> And we CanSeeTarget</code></li> Call a delegate</a> (NewTargetSeen</code>)</li> In the Controller: Call MovementBehaviour</code> when the Character's NewTargetSeen</code> event fires</li> </ul> </li> </ul> </li> </ul> Note: Both of these methods should improve behaviour for both "it" and "not-it" bots! However, they both have pros and cons - the first might be a little bit more responsive (depending on how you tune the Tick Interval) - but it means all of our bots use the Tick event, which is slow. We'll eventually replace this with the built-in Unreal Engine Perception System</a> and get the best of both worlds! </blockquote> </div> </details> Navigation: Filtering and Avoidance</h2> Finally, lets give our "not-it" bots a chance to get away. Lets filter our Navigation so that "it" bots don't try to use Launchpads to move, and lets make the AI try and adjust its movement so even if it's running straight past someone, it triesto avoid touching it. Blueprint: Filtering</summary> We're no longer going to be able to use the Simple Move to Actor</code> node - our move is just not that simple anymore. However, it's got a nice and predictable behaviour, there's only one predicate - if our Character is Tagged</code> or not! What we're going to do is make a new function which pretends to be a Simple Move to Actor</code>, and handles the additional logic! To do so, find one of our calls to Simple Move to Actor</code>, select that node and the preceding self</code> node, right click and collapse to function: </picture> </figure> Name our new function Move to Actor</code>, and then go ahead and find and replace all current calls of Simple Move to Actor</code> with our new function. Tip: You can use ctrl</code> + F</code> to find nodes, just like a text editor. </blockquote> Inside the function, we now want to replace Simple Move to Actor</code> with Move To Actor</code>: </picture> </figure> Finally, lets add a Navigation Filter if we're tagged, and use the default Navigation Filter if we're not. We're going to do three things to set this up: Create a new NavArea_Launchpad</code>, the same way we created NavArea_Stairs</code> in the last post</a>.</li> Create a new NavFilter_Tagged</code>, which is a new blueprint based on the NavigationQueryFilter</code> class, and add the Area as excluded:</li> </ol> </picture> </figure> In our Move To Actor</code> function, Select</code> which Navigation Filter we're going to use, based on our Character's Tagged</code> state:</li> </ol> </picture> </figure> And that's it! Now our "not-it" AI has a chance to get away! Note: The "it" AI can still use the launchpads if they accidentally run over them - feel free to fix that if it bothers you! </blockquote> </div> </details> Blueprint: Avoidance</summary> Setting up avoidance in our Character is quite easy, to get the basics right. Simply making every agent avoid every other one just requires turning on RVOAvoidance</code> on the Character Movement Component</code>. Ensure that the Avoidance Weight is set to 0.5 as well - a good default value which you can tweak as desired. </picture> </figure> If you wanted to tweak this so that It and Not-it have different behaviour, you'll want to set up this information using the Avoidance Groups. For example, set It bots to Avoidance Group 1, and have them Ignore Group 0 for avoidance purposes. For Not-it bots, leave them as Avoidance Group 0, and let them avoid both Group 0 and 1. Tip: Unreal offers a slightly more advanced form of Avoidance called Detour Crowd Avoidance, which is slightly "better" than RVO - but we'll implement it another time! </blockquote> </div> </details> C++: Filtering</summary> Generally, when we call MoveToActor</code>, we're just passing in the first argument. However, we now want to start passing in a Filter as well, and (for now), keep the rest of the arguments default. To do this simply, we're going to wrap the AAIController</code>'s method with our own: // TagController.h private: UFUNCTION() void TaggedMove(AActor* Goal); </code></pre> The implementation is going to be incredibly simple: // TagController.cpp void ATagController::TaggedMove(AActor * Goal) { TSubclassOf<UNavigationQueryFilter> FilterClass = nullptr; if (TagCharacter->Tagged) { FilterClass = UNavFilter_Tagged::StaticClass(); } MoveToActor(Goal, -1.0f, true, true, true, FilterClass, true); } </code></pre> Go back and replace all calls of MoveToActor</code> with our new TaggedMove</code>. As you can see, we're going to need a new class - UNavFilter_Tagged</code>. Create this as a child of UNavFilter_AIControllerDefault</code></a>. Add a default constructor for our UNavFilter_Tagged</code>: // NavFilter_Tagged.cpp UNavFilter_Tagged::UNavFilter_Tagged() { FNavigationFilterArea FilterArea { }; FilterArea.AreaClass = UNavArea_Launchpad::StaticClass(); FilterArea.bIsExcluded = true; Areas.Add(FilterArea); } </code></pre> We're also going to have a create a UNavArea_Launchpad</code>, from UNavArea</code></a> - but we won't need to add any code to it. We will, however, adjust our ALaunchpad</code> class to use it: // Launchpad.cpp - ALaunchpad::UpdateNavLinks() Link.SetAreaClass(UNavArea_Launchpad::StaticClass()); </code></pre> And that's it! Now our "not-it" AI has a chance to get away! Note: The "it" AI can still use the launchpads if they accidentally run over them - feel free to fix that if it bothers you! </blockquote> </div> </details> C++: Avoidance</summary> Setting up avoidance in our Character is quite easy, to get the basics right. Simply making every agent avoid every other one just requires setting the UCharacterMovementComponent::bUseRVOAvoidance</code> flag to true!. You can do this in either blueprint or C++. Ensure that the AvoidanceWeight</code> is set to 0.5 as well - a good default value which you can tweak as desired. Tip: Unreal offers a slightly more advanced form of Avoidance called Detour Crowd Avoidance, which is slightly "better" than RVO - but we'll implement it another time! </blockquote> </div> </details> Wrapping up</h2> Now you know how to set up Navigation Filtering, how to get your AI to avoid each other, and hopefully have learned a little bit about best practices in UE4! </figure> Everything might be feeling a little complicated now - especially in Blueprints - but we start using more powerful tools to help us from here. For the next post (which is hopefully a little shorter), we're going to start looking at the in-built UE4 advanced AI system - Behaviour Trees! Tip: You can visualise what your AI is doing by using the AI Debug view. To enable this in the editor, look under Show -> Developer -> AI Debug. Clicking on one of your AI controlled bots will then show what path they're taking, as well as hordes of other useful info to help you debug! </picture> </figure> </blockquote> I'd love to hear whether you're following along using blueprints or C++ (or both)! Email me</a> and let me know! You can subscribe to this blog using any old RSS reader, if it tickles your fancy to follow along! Just plug https://vikram.codes/blog</code></a> into your RSS reader of choice and it should work. </blockquote> Navigation Modifiers and Links in UE4 Vikram Saran — Sun, 05 Nov 2017 00:00:00 +0000 Introduction</h2> Continuing on from navigation basics we covered in the last post</a>, we're going to have a look at how we can extend the NavMesh to do all sorts of cool things. If you haven't followed along, or just want to make sure you're on the same page, you can download what we've done so far</a> from the GitLab repository</a>. </blockquote> The topics that we're going to cover include: Nav Mesh Links</li> Nav Mesh Areas and Nav Mesh Modifiers</li> Navigation Filters</li> Using Navigation for AI that have different sizes</li> Runtime Nav Mesh Generation</li> </ol> As you can tell, there's quite a bit to cover! To make it easier to follow, I'll be splitting this up into two articles, with this one covering Navigation Links, Areas, and Modifiers. Specifically, we're going to add: a preference for the AI to avoid the stairs</li> the ability for the AI to jump off the raised platform</li> a launchpad that launches a bot onto the platform</li> </ul> Note: Unreal Engine 4.18 was released while this blog post was being written. This post will continue to use 4.17, although the codebase may be updated for the next post in the series (and a download link will be provided). </blockquote> Nav Areas</h2> Before we start making anything, we'll begin by discussing the idea of navigation areas. By default, all areas of a NavMesh are entirely equal. The AI only ever considers distance when determining what path it wants to take. We call this the "cost function". If we wanted the AI to avoid certain areas, we would need to make it "cost" something to enter or to traverse the area. We could make it "heavier" or "lighter" than the rest of the map to create preferences. Unreal Engine uses the concept of a Nav Area for this. We can create our own areas the same way we create any class (in either Blueprints or C++): </picture> </figure> Once we've created an area, we can tweak a few simple settings (C++ can do a lot more, but we'll cover that later). </picture> </figure> Default Cost</code> is used to make walking through an area be more or less attractive. The default area cost is 1.0. This is multiplied by the distance that the AI would have to walk through the area, so higher numbers cause the AI to avoid that zone. Fixed Area Entering Cost</code> can be used for things like the "oil spills" in Divinity: Original Sin, that apply a status effect when you first enter the zone. Also, we can edit which colour is used to represent the Nav Area. The Default Nav Area class uses a light green, and visualising where the other areas are can help our level designers. Lets create a NavArea_Stairs</code> and set the Default Cost</code> to 1.2, and the colour to a yellow/orange. We'll apply this in a second using... Note: if you want to do this in C++, I'm sure you can figure it out! Just subclass the UNavArea</code></a> class and set the values you'd like in the constructor. </blockquote> Nav Modifiers</h2> Nav Areas can be applied in a few different ways. The main method for marking a space in your game as a specific Nav Area is the Nav Modifier Volume</code>. </picture> </figure> When you first drag one onto the stairs, you'll notice that it actually deletes the NavMesh! </picture> </figure> This is because the Area Class</code> is set to NavArea_Null</code>. Lets change it to our Nav Area that we created: </picture> </figure> The moment we do that, however, the stairs go back to green! This is because there is currently a bug in UE4 regarding custom Nav Areas</a>. There is a simple fix for now, just restart the editor and move your nav area slightly to force a rebuild! You should then see your stairs highlighted in your chosen colour - showing that the area has been applied properly. </picture> </figure> Nav Link Basics</h2> Our next challenge is to add the ability for the AI to "drop" from one part of the NavMesh to another part, without having to go around. </picture> </figure> Basically, we want to create a 'link' from one predetermined point on the mesh to another, which the underlying algorithm can't find by itself. Fortunately, Unreal Engine provides us with the incredibly useful Nav Link Proxy Actor</code>. </picture> </figure> When you drag one into the scene, you'll see this: </picture> </figure> And it's details panel looks like this: </picture> </figure> This actor has some quirks, however, so lets make sure we're on the same page. Mainly, a Nav Link Proxy has two types of links that we can create: Simple links and Smart Links. All links</h3> Both Simple and Smart Links have the following in common: They have a "left" and a "right"</li> They have a direction: Left to Right</li> Right to Left</li> or Both ways</li> </ul> </li> They can be assigned a Nav Area</li> </ul> Simple Links</h3> Exist in an Array (called Point Links</code>) i.e. you can have multiple Simple Links per Nav Link Proxy</li> Each Nav Link Proxy actor comes with one element in the array by default</li> </ul> </li> Visible in the Scene The Left</code> and Right</code> visible elements are from the default Simple Link in the Actor</li> This makes Simple Links easy to move around and place in the scene</li> </ul> </li> </ul> Smart Links</h3> Disabled by default Turn on by ticking Smart Link Is Relevant</code></li> </ul> </li> Can be turned on and off at runtime And will notify nearby actors who want to know!</li> </ul> </li> No visible editor You have to manually enter the Left/Right location via the Details panel</li> </ul> </li> Only one Smart Link per Nav Link Proxy</li> </ul> Practical Example</h3> Lets make a simple nav link first, and we can play with the advanced options later on. If we just want our bot to be able to jump off the cliff, lets put our Proxy Actor in the middle, and set up a few simple links like so: </figure> Note: There are three simple links from one Nav Link Proxy</code>, and each has been set as a Left to Right</code> link. </blockquote> This easy setup will allow our AI to path off of that ledge - it's that simple! </figure> Nav Link Advanced Usage</h2> If we want to create a two-way Nav Link (or a Nav Link that doesn't just fall down a cliff), we need to have a way of moving our AI from one place to the other. This isn't very difficult to do, but can be a bit hard to wrap your head around when starting out. We're going to create a Launchpad actor (similar to the Blueprint Quick Start</a>), which will launch our AI to a specific point, and work with our Nav Mesh. There are a few different ways to do this in C++, so for now we're just going to use a simple method that mimics what we can do in Blueprints. We'll investigate other options in later posts. Blueprint: Launchpad</summary> Unfortunately, this isn't currently possible to do in Blueprints only (I will be submitting a Pull Request after this blog post goes live, to try and get it working for 4.19)! We're going to have to create a little C++ helper class. The following steps will get you back into blueprints pretty quickly. C++ Nav Link Component</h3> Create a C++ Class based on the NavLinkComponent</code>. You'll need to tick "Show All Classes". Call it BlueprintableNavLinkComponent</code>. </picture> </figure> Once the class has been created and opened, we're going to have to edit two files. One is called BlueprintableNavLinkComponent.h</code> and is known as a "header" file, the other has the .cpp</code> extension as is called a "source" file. We'll make two slight additions to the header file. Firstly, find the line that looks like UCLASS()</code>, and add meta = (BlueprintSpawnableComponent)</code> in between the brackets, so it looks like: UCLASS(meta = (BlueprintSpawnableComponent)) </code></pre> Then, add the following two lines of code under the GENERATED_BODY()</code> line: UFUNCTION(BlueprintCallable) void SetupLink(FVector Left, FVector Right, ENavLinkDirection::Type Direction); </code></pre> This declares that we want to create a function called Setup Link</code> which accepts two Vector input pins and a Link Direction. In the source file (BlueprintableNavLinkComponent.cpp), add the following code: void UBlueprintableNavLinkComponent::SetupLink(FVector Left, FVector Right, ENavLinkDirection::Type Direction) { this->Links[0].Left = Left; this->Links[0].Right = Right; this->Links[0].Direction = Direction; } </code></pre> This says that when we call the function, get the first link in the Links array (which has an index of 0</code>) and assign the values which we pass in to the function. Remember that the Simple Links</code> array has one value by default, this is the value that we're changing now! If you wanted to be able to set values for multiple simple links, you'd want to change the 0</code> using another input parameter - and you'd have to check that link existed too! </blockquote> Blueprint Launchpad</h3> Now we've done that, we can jump back into blueprints and create a class (based on an Actor), which has the following components: Root: Scene Component Static Mesh Collider (I used a sphere)</li> </ul> </li> Billboard</li> Blueprintable Nav Link</li> </ul> </li> </ul> </picture> </figure> Select any mesh that you like (I use a flatish hexagonal cylinder). Then, add a Vector variable called Target</code>, set its default value to (200, 0, 0)</code>, and check both Instance Editable</code> and Show 3D Widget</code> in the details panel. </picture> </figure> Now we can start writing some scripts to make this useful! To make it work with Nav Meshes, all we need to do is call the the function we created in the Construction Script! </picture> </figure> Now we can drag the actor into our scene, and set it up! You should notice that when you drag around the Target</code> widget, the Nav Link automatically updates to point towards it! Note: You can't use a Component as a Target, it has to be a plain Vector, because of a known issue in the engine</a>. </blockquote> </picture> </figure> Now we need to make the AI get launched when they touch our collider. This will require a new function - Calculate Launch Velocity</code>. This function is pretty simple, if we use Unreal's in-built capability to Suggest Projectile Velocity</code>. Specifically, we can use Custom Arc</code> version of the node, which is a bit easier to make work: </picture> </figure> Tip: You can split Structs</code> (like Vectors) by right clicking on them! This is handy when you just want to utilise one component, like the Z axis value, above. </blockquote> Note: If you wanted this Launchpad to only launch up to a certain velocity, you could use the base version of this node. However, you'd probably want to add a Construction Script check that the destination was reachable! </blockquote> Now we need to utilise this calculation. Unfortunately (See Issue #1, below), we can't use the Launch Velocity</code> node. We have to do the following instead: </picture> </figure> Note: This is the perfect place to use a Custom Movement Mode, but for now we're just going to use the "falling" mode, which is perfectly fine to override the way we're doing it. </blockquote> This almost works! If you run it now, you'll see your AI launching correctly, but then halfway through the jump they fall straight down. Blueprint Character</h3> This appears to have something to do with the Controller</a>. The default Controller logic will stop the Character's X and Y movement at the apex of a jump (apparently because the default AIController</code> isn't designed to deal with external movement</a>). To make this work, we need to disable the Path Following Component</code> on our character when we jump, and then re-enable it when we land! There are two functions already provided for us in the Character</code> class, which we can override in our blueprint (BP_TagCharacter</code>) - On Landed</code> and On Movement Mode Changed</code>! Override the On Movement Mode Changed</code> function under the function section on the blueprint: </picture> </figure> The first thing to do is to make sure we still call the default logic for this event. Do this by adding a call to the parent function: </picture> </figure> Then, if the movement mode changed to Falling</code>, we want to get the AIController</code> (if any) and Deactivate</code> the Path Following Component</code>: </picture> </figure> Our AI will now jump all the way to end of our nav link path! Although once it gets there, it's just going to stand still. To fix this, lets add a similar bit of logic by overriding the On Landed</code> event to re-activate the Path Following Component</code>: </picture> </figure> And that's it! We've now got a shortcut for AI to get up on the ledge without having to go up the stairs - and the AI will properly follow our path using physics! </div> </details> C++: Launchpad</summary> Our first C++ method is (nearly) identical to the BP method above. In fact, this is simpler to do in C++ because we don't have to create a custom UNavLinkComponent</code></a> to be able to edit the properties! We'll create one class (ALaunchpad</code>) and edit our ATagController</code> class a little bit, and that's it. Launchpad</h3> For ALaunchpad</code>, create a new class derived from AActor</code>, and fill the header out with the following: public: ALaunchpad(); UPROPERTY(VisibleAnywhere) class USceneComponent Root; UPROPERTY(VisibleAnywhere) class UStaticMeshComponent Launchpad; UPROPERTY(VisibleAnywhere) class USphereComponent TriggerVolume; // This component's details are automatically set in the Construction Script UPROPERTY(VisibleAnywhere) class UNavLinkComponent NavLink; UPROPERTY(EditAnywhere, BlueprintReadWrite, meta = (MakeEditWidget = "")) FVector Target; UFUNCTION(BlueprintPure) FVector CalculateLaunchVelocity(AActor* LaunchedActor); // When our Trigger Volume overlaps with something, this function gets called UFUNCTION() void OnTriggerBeginOverlap(UPrimitiveComponent* OverlappedComp, AActor* Other, UPrimitiveComponent* OtherComp, int32 OtherBodyIndex, bool bFromSweep, const FHitResult& SweepResult); private: UFUNCTION() void LaunchCharacter(ACharacter* Character); // Whenever we edit the Actor Transform or any properties via the Details panel, this will trigger. void OnConstruction(const FTransform& Transform) override; // Update the Nav Link Component to link from the Mesh to the Target void UpdateNavLinks(); </code></pre> This sets up our basic Components (a Root, a Mesh, a Trigger Collider, and our Nav Link), a single public UPROPERTY</code> for our target destination, and a few functions. Note: The LaunchCharacter function must be a UFUNCTION</code> to work with Binding, which we'll use in our constructor. </blockquote> Note: We use meta = (MakeEditWidget = "")</code> to make our FVector have a visible 3D Widget in the editor, this makes it nice and easy for our designers to use our class. </blockquote> Note: you can set up any kind of Collider component that you like instead of a Sphere. For my particular Launchpad mesh, the Sphere works perfectly. </blockquote> Don't forget to add the following includes: #include "Components/StaticMeshComponent.h" #include "Components/SphereComponent.h" #include "AI/Navigation/NavLinkComponent.h" </code></pre> Now we can write our source file. At the top, include the following: #include "UObject/ConstructorHelpers.h" #include "Kismet/GameplayStatics.h" #include "GameFramework/Character.h" #include "GameFramework/CharacterMovementComponent.h" #include "AI/Navigation/NavigationSystem.h" </code></pre> For the constructor, we simply set up our components and default values to reasonable defaults (including loading a mesh), and then we need to bind a delegate</a>, so that when the TriggerVolume</code> component begins to overlap with another actor, our OnTriggerBeginOverlap</code> function is called. ALaunchpad::ALaunchpad() { // We don't need our Launchpad to Tick PrimaryActorTick.bCanEverTick = false; // Create our Components and setup default values Root = CreateDefaultSubobject<USceneComponent>(TEXT("Root")); RootComponent = Root; Launchpad = CreateDefaultSubobject<UStaticMeshComponent>(TEXT("Launchpad")); Launchpad->SetupAttachment(Root); Launchpad->SetRelativeLocation(FVector::ZeroVector); // Load the Launchpad Mesh from our Content folder static auto LaunchpadMesh = ConstructorHelpers::FObjectFinderOptional<UStaticMesh>(TEXT("/Game/Meshes/SM_Launchpad")); if (LaunchpadMesh.Succeeded()) { Launchpad->SetStaticMesh(LaunchpadMesh.Get()); } TriggerVolume = CreateDefaultSubobject<USphereComponent>(TEXT("Trigger Volume")); TriggerVolume->SetupAttachment(Launchpad); TriggerVolume->SetSphereRadius(25.f, true); NavLink = CreateDefaultSubobject<UNavLinkComponent>(TEXT("Nav Link")); NavLink->SetupAttachment(Root); // Set a default target to be slightly outside our mesh Target = { 100.f, 0.f, 0.f }; // Bind so that when the trigger gets touched we get notified TriggerVolume->OnComponentBeginOverlap.AddUniqueDynamic(this, &ALaunchpad::OnTriggerBeginOverlap); } </code></pre> Note: If you make a mistake with the Constructor Helper line (ConstructorHelpers::FObjectFinderOptional<UStaticMesh>(TEXT("/Game/Meshes/SM_Launchpad"));</code>), it may cause your project to crash upon opening. It's easy enough to open the code file and comment it out. Just be careful with the line and you should be ok! Consider yourselves warned. </blockquote> At this point, create empty functions for all of the signatures we created. We're going to quickly get this working nicely with the Nav Links, before moving back to working on the AI side of things. To get the Nav Link to update every time we edit the Target vector, we can use the OnConstruction</code> function, which works exactly like the Construction Script in blueprints! To make this clean and easy to read, we create a simple function helper UpdateNavLinks</code> as well: void ALaunchpad::OnConstruction(const FTransform& Transform) { Super::OnConstruction(Transform); UpdateNavLinks(); } void ALaunchpad::UpdateNavLinks() { // We should never manually edit this actor's links. NavLink->SetRelativeLocation(FVector::ZeroVector); // Assert that we haven't added or removed any Simple Links check(NavLink->Links.Num() == 1); // Setup link properties auto& Link = NavLink->Links[0]; Link.Left = FVector::ZeroVector; Link.Right = Target; Link.Direction = ENavLinkDirection::LeftToRight; // Force rebuild of local NavMesh auto World = GetWorld(); if (World) { auto NavSystem = World->GetNavigationSystem(); if (NavSystem) { NavSystem->UpdateComponentInNavOctree(NavLink); } } } </code></pre> Now you should be able to place your actor in the world and move around the Target widget, and see the Nav Link updating in the editor! </picture> </figure> Next, we want to have the AI actually get launched! We'll need to handle our trigger event at this point. Our OnTriggerBeginOverlap</code> function is quite simple, it just calls our LaunchCharacter</code> function if the overlapping actor is the right type: void ALaunchpad::OnTriggerBeginOverlap(UPrimitiveComponent OverlappedComp, AActor* Other, UPrimitiveComponent* OtherComp, int32 OtherBodyIndex, bool bFromSweep, const FHitResult& SweepResult) { auto Character = Cast<ACharacter>(Other); if (Character) { LaunchCharacter(Character); } } </code></pre> Note: you may run into issues where the Character doesn't believe that it sucessfully reached the entry point of the Nav Link. If that happens, your trigger collider may be too wide! You can resolve this issue by using a Timer</a> to wait a short time (0.1s is likely enough) before launching the character. </blockquote> Our LaunchCharacter</code> function is fairly simple, although not as perfectly simple as we'd like - because the in-built ACharacter::LaunchCharacter</code> function doesn't allow us to set X/Y movement when using Root Motion animations (see Issue #1, below)! void ALaunchpad::LaunchCharacter(ACharacter* Character) { // Set the Velocity and Mode manually auto MovementComponent = Character->GetCharacterMovement(); MovementComponent->Velocity = CalculateLaunchVelocity(Character); MovementComponent->SetMovementMode(EMovementMode::MOVE_Falling); } </code></pre> Note: the above is the perfect place to use a Custom Movement Mode</a>! We use the in-built Falling</code> movement mode, but you could use a Custom one if you wanted. </blockquote> Our Launch Velocity calculation is quite simple, thankfully, due to the SuggestProjectileVelocity</code></a> function which UE4 provides for our use (specifically the simpler _CustomArc</code></a> version): FVector ALaunchpad::CalculateLaunchVelocity(AActor* LaunchedActor) { // Launch from the "feet" of the Character auto Start = LaunchedActor->GetActorLocation(); Start.Z -= LaunchedActor->GetSimpleCollisionHalfHeight(); // Launch to the Target in WS auto End = GetActorTransform().TransformPosition(Target); FVector Result; UGameplayStatics::SuggestProjectileVelocity_CustomArc(this, Result, Start, End); return Result; } </code></pre> And with all that, we should have a perfectly working launchpad! But if you try it out... our AI "derps" a little bit! In the middle of the jump, the AI stops moving along the X/Y direction, and just falls straight down. Controller</h3> To fix this, we're going to have to tweak our ATagController</code> class. Actually, we're going to tweak the ACharacter</code> class and add some additional logic to the Landed</code> and OnMovementModeChanged</code> functions. We could do this in two ways: we could either create a ATagCharacter</code> and just override the two functions, or we can bind the events from our ATagController</code> and create two functions to handle it. It's slightly more complicated to do it via the Controller, but I believe that it's the "better" option, so lets do it that way. This is because we're going to be accessing the Controller inside our handlers anyway - it's Controller logic that we're handling, but triggered by the Character events! </blockquote> Create the following two functions in our ATagController</code>: private: UFUNCTION() void OnMovementModeChanged(ACharacter* MovedCharacter, EMovementMode PrevMovementMode, uint8 PreviousCustomMode = 0); UFUNCTION() void OnLanded(const FHitResult& Hit); </code></pre> At the end of our ATagController::BeginPlay()</code>, we want to bind these to the events in our Character: auto Character = GetCharacter(); if (Character) { Character->MovementModeChangedDelegate.AddUniqueDynamic(this, &ATagController::OnMovementModeChanged); Character->LandedDelegate.AddUniqueDynamic(this, &ATagController::OnLanded); } </code></pre> And finally, we want to fill them out. Whenever the character enters the Falling</code> state, we want to Deactivate</code> the UPathFollowingComponent</code></a> of the Controller. Whenever we land, we just re-enable it! void ATagController::OnMovementModeChanged(ACharacter* MovedCharacter, EMovementMode PrevMovementMode, uint8 PreviousCustomMode) { // If the new movement mode is Falling if (MovedCharacter->GetCharacterMovement()->MovementMode == EMovementMode::MOVE_Falling) { GetPathFollowingComponent()->Deactivate(); } } void ATagController::OnLanded(const FHitResult & Hit) { GetPathFollowingComponent()->Activate(); } </code></pre> And now our AI won't stop mid-air - and that's all we need to do to have a working Launchpad! Note: An even more "correct" way to do this, rather than deactivating the PathFollowingComponent, would be to use a custom movement mode, which we will explore in a later post. </blockquote> </div> </details> Wrapping up</h2> Now you know how to modify the Nav Mesh to make it as accessible, or inaccessible, as you would like! </figure> For the next post</a>, We continue with navigation, making our AI act differently as it reaches different sections of our mesh, and finish the basic "game" logic! Want to get in touch? Email me</a> and let me know! You can subscribe to this blog using any old RSS reader, if it tickles your fancy to follow along! Just plug https://vikram.codes/blog</code></a> into your RSS reader of choice and it should work. </blockquote> Issues</summary> Unfortunately, simply using Launch Character</code> does not work! This appears to be</a> because the mesh/animation set we are using uses Root Motion. To work around this, we Set Velocity</code> on the Movement Component directly, and then Set Movement Mode</code> to Falling. </li> Even with the above fix, the Character stops moving at the Apex of the jump. </li> The default Controller logic will stop the Character's X and Y movement at the apex of a jump (apparently because the default AIController</code> isn't designed to deal with external movement</a>). </li> Deactivating and reactiving the PathFollowingComponent will fix this issue. </li> In future installments, we'll investigate writing our own PathFollowingComponent and Movement Mode which will handle this for us. </li> </ul> </li> It's impossible to edit Nav Link component Simple Links in Blueprints - this makes us need the BlueprintImplementableNavLink</code> This is because the FVector FNavigationLink.Right</code> is not marked BlueprintReadWrite</code> in the engine source code. </li> If that property was marked as such, we could make the nav link work entirely via construction script, instead of requiring the C++ component class (hook up the Target Relative Location to the added Right</code> input node): </li> </ul> </li> </ol> </picture> </figure></div> </details> Basic Navigation in UE4 Vikram Saran — Fri, 13 Oct 2017 00:00:00 +0000 Introduction</h2> There exist a large</a> number</a> excellent</a> resources</a> for game developers seeking to learn how to utilise the in-built AI features in Unreal Engine 4. Unfortunately, a number of these are outdated</a> or teach only specific elements</a> or are part of large tutorial series</a> or assume knowledge</a> that you might not have. This blog series aims to provide context and teach best practices for utilising the AI systems available in Unreal Engine 4 (version 4.17). It is aimed at beginning-to-intermediate developers, covering both C++ and Blueprint usage of AI. Each post will show Blueprint scripts first and then show how to achieve the same results in C++. It is assumed that you have basic understanding of how to use the engine and editor and have, at least, followed the official Blueprint</a> or Programming</a> Quick Start Guides. Goal</h2> Over the next few blog posts, we're going to build an AI-only "Game of Tag" demo project. We'll do this one step at a time, starting with an (almost) entirely blank project, and then building up the demo with proper usage of the Unreal Engine Gameplay Framework</a>. This first post will look at how we can get our AI to move. We'll be using the Unreal Engine Navigation System to do so. Setting Up the Project</h2> Download the provided project template</a>. This minimised project file includes the mannequin (from the UE4 templates) and a basic Character blueprint (BP_TagCharacter</code>) with the Mesh and Animation Blueprint setup (and correctly scaled/rotated components), and a rudimentary geometry-based level for testing purposes. Alternatively, if you are using git, you can access the project from the GitLab repository</a>. The initial download commit has the template tag, and the state of the codebase at the end of any blog post is also tagged with the name of the post (e.g. basic-navigation). Setting up the Nav Mesh</h2> Before we do anything advanced, lets take a small step first - making our AI Characters walk around using the UE4 Navigation System. The Unreal Engine navigation system utilises a Nav Mesh (Navigation Mesh) to know where the walkable sections of our level are. To tell UE4 to build a nav mesh, let's go ahead and add a Nav Mesh Bounds Volume to the level, and resize it so that it fits all of the walkable space in our level! </picture> The Nav Mesh Bounds volume can be found in the placement panel</figcaption> </figure> Once you've fit the bounds, press P to make the Nav Mesh visible. </picture> The Nav Mesh Bounds volume can be seen with the P key</figcaption> </figure> When you add the Volume to the level, you'll notice that a RecastNavMesh-Default</code> actor was added as well. This actor has settings we can use to visualise different elements of our NavMesh, and we can also tweak how it's generated. </picture> The Recast NavMesh actor can be found in the World Outliner</figcaption> </figure> We should start by setting up the Agent Radius and Height to be 44.0 and 192.0 to match our Character. This will cause the NavMesh to properly identify all of the walkable areas of our game for our specific Character size. Once we've done that, we can edit the Cell Size from 19.0 to 5.0 to improve the accuracy of the walkable space available (especially on our stairs): Cell Size 19.0</th> Cell Size 5.0</th></tr></thead> </picture> </figure> </td> </picture> </figure> </td></tr> </tbody></table> This does take some more time to generate the NavMesh, so it's not perfectly suitable for all games, but for our demo this will be fine. Note: Test your Nav Mesh now. It may not properly appear (or may disappear when you simulate the game). If this is the case, close and re-open your project and force the mesh to rebuild (by moving it a bit, then shift it back). This is likely due to strange interactions with BSP/Geometry based levels. Ensure that your nav mesh appears as in the picture above, and that it is still visible if you Simulate (Alt+S</code>) the game Moving Around</h2> Our next step is to get a single AI Character into the game and moving around. To do this properly, we're going to create a custom AI Controller class which will pick a random "waypoint" and move the AI there, and then wait before continuing again. Let's first set up our "Waypoints" around the map. To make this quick and easy, drag in a few Target Point</code> actors into various locations around our map: </picture> Target Points can be added via the Placement Panel</figcaption> </figure> We're then going to create a new Class based on the AI Controller class to control our AI. The following instructions are given both in Blueprint and C++, so pick which one you want to work with. Tip: An AIController is used as the "brain" of a Pawn or Character. Much like a PlayerController, it mainly is concerned with determining what the Character wants to do next, rather than whether it can (i.e. Controllers should contain Input/Intelligence, and Pawns should contain Game Logic). </blockquote> Blueprint: AI Controller</summary> Create a new Blueprint Class, and when asked for the Parent Class, go into the All Classes section, select AI Controller, and create our BP_TagController</code>. </picture> </figure> The first thing that our Tag Controller should do is find and store a reference to all of the Waypoints in our level. We can do this using the Get All Actors Of Class</code> node: </picture> </figure> We then want to be able to Get Random Waypoint</code>, so lets create a function which does exactly that (Note: I marked this function Pure</a> as it does not change any State): </picture> </figure> Finally, we're going to Go To Random Waypoint</code> a lot, so lets create that function, and call it on Begin Play. </picture> </figure> But what goes into this function? This is where we start using the UE4 Navigation system. We actually have 4 options for which node to use, depending on whether we want to move to an Actor or Location, and whether we want to use a simple version of the function or one with all of the details: </picture> </figure> For now, we're just going to use the simplest possible variation - Simple Move to Actor</code>, and feed in a random waypoint: </picture> </figure> And our basic Controller is all done! </div> </details> C++: AI Controller</summary> Create a new C++ class based on the AIController</code></a> class called TagController</code>. You will need to check Show All Classes. Tip: whenever I mention an Unreal Engine API class or function, I will link it directly to any available online documentation. Go ahead and click on AIController</code></a> to learn about what we're overriding. </blockquote> </picture> </figure> Our AI is rather simple, all we need is to override</code> the BeginPlay()</code></a> function, and to create the following UFUNCTION</code></a>'s and UPROPERTY</code></a>. Note: Every time you use an Unreal Engine class, you need to #include</code> it, they are not included by default. Don't forget to #include "Engine/TargetPoint.h"</code> </blockquote> public: void BeginPlay() override; private: UPROPERTY() TArray<AActor> Waypoints; UFUNCTION() ATargetPoint GetRandomWaypoint(); UFUNCTION() void GoToRandomWaypoint(); </code></pre> Now lets fill in our functions. Firstly, Begin Play will store all of the Waypoints in the game. To do this, we're going to use UGameplayStatics::GetAllActorsOfClass</code></a>, as per the second answer on this answerhub question</a>. Then, all we need to do is call GoToRandomWaypoint</code>, which we will fill in shortly. Again, you'll need to include a new header file. This time you want to #include "Kismet/GameplayStatics.h"</code> </blockquote> void ATagController::BeginPlay() { Super::BeginPlay(); UGameplayStatics::GetAllActorsOfClass(GetWorld(), ATargetPoint::StaticClass(), Waypoints); GoToRandomWaypoint(); } </code></pre> Note: Don't forget to call Super::BeginPlay()</code> If you don't - your character will never move, and you'll spend hours trying to figure out what you forgot! </blockquote> Before we can GoToRandomWaypoint</code>, we need to GetRandomWaypoint</code>, so lets use UE4's FMath</code></a> library to do so. We're also going to Cast</code></a> our return value so that it's the correct type: ATargetPoint* ATagController::GetRandomWaypoint() { auto index = FMath::RandRange(0, Waypoints.Num() - 1); return Cast<ATargetPoint>(Waypoints[index]); } </code></pre> Finally, lets fill in the GoToRandomWaypoint</code> function. This has a few options from the AIController</code></a> - MoveTo</code></a>, MoveToActor</code></a>, and MoveToLocation</code></a>. We're going to use the simplest possible option for now - MoveToActor</code></a>, with all of the default arguments: void ATagController::GoToRandomWaypoint() { MoveToActor(GetRandomWaypoint()); } </code></pre> And that's it! </div> </details> Using the Controller</h2> Now that we've got our "brain" built, it's time to fit it into our "body". To do so, open up the BP_TagCharacter</code> and look for the Pawn's AI Controller Class variable, and set it to your custom controller: </picture> </figure> Compile, save, and drag an instance of the Character into the scene. Run, and you should have an AI that runs to a random waypoint! Make sure to stop and start a few times to test it out fully! </figure> Adding further movement</h2> At this point, we've covered everything required to make our AI move around the map, but our bot is a little stupid right now. Let's make it a little bit smarter by making it wait a short while once it reaches its destination, before picking and moving to another random waypoint. Again, this section is split up for Blueprints and C++. Blueprint: ReceiveMoveCompleted</summary> To do this, we're going to need to know when the AI has completed moving. We can do this by binding a custom event to ReceiveMoveCompleted</code>. We want to bind the event on Begin Play (so that when we finish any movement in the game it is called), so add it like so: </picture> </figure> This custom event will be triggered by UE4 whenever any navigation movement finishes, as long as the bind node ran first. Note: To be fully correct, you want to bind the event before calling Go To Random Waypoint</code>. This is wise in case the movement fails for any reason (such as you forgetting to put in Target Point actors), because the Result struct will provide you with debugging information. </blockquote> Once movement finishes, we should wait a short while, and then call Go To Random Waypoint</code> again. </picture> </figure></div> </details> C++: OnMoveCompleted</summary> In C++, doing something immediately when a move is completed is even easier than in Blueprints - thanks to the AIController::OnMoveCompleted</code></a> virtual function! All we need to do is overwrite the function in our header file: public: void OnMoveCompleted(FAIRequestID RequestID, const FPathFollowingResult& Result) override; </code></pre> And if we didn't want to wait a second once we reached our target, the function implementation would be trivial! void ATagController::OnMoveCompleted(FAIRequestID RequestID, const FPathFollowingResult & Result) { Super::OnMoveCompleted(RequestID, Result); GoToRandomWaypoint(); } </code></pre> But adding the equivalent of a Delay node for 1 second is a touch tricky - we're going to need to use an FTimerHandle</code></a>. Add one to your header file: private: FTimerHandle TimerHandle; </code></pre> And we can then use the SetTimer</code></a> function to call GoToRandomWaypoint</code> after a second, rather than directly calling it ourselves: void ATagController::OnMoveCompleted(FAIRequestID RequestID, const FPathFollowingResult & Result) { Super::OnMoveCompleted(RequestID, Result); GetWorldTimerManager().SetTimer(TimerHandle, this, &ATagController::GoToRandomWaypoint, 1.0f, false); } </code></pre> Note: The GetWorldTimerManager()</code> function may give you a warning of "incomplete type is not allowed" - but it will compile and work perfectly. </blockquote> </div> </details> Wrapping up</h2> We now have the basics set up to control a Pawn, and move it around the level using AI! </figure> For the next post, I'm actually undecided which way I want to go! I'm tossing up between starting on the Behaviour Tree for our AI (making them "think"!), or continuing with navigation, making our AI act differently as it reaches different sections of our mesh, using custom Movement Modes and Path Following Components. What do you think? Email me</a> and let me know! Tip: You can view lots of information about your NavMesh and whether your AI can get from one point to another by using the Navigation Testing Actor. To use them, drag two into your level, and on one of the instances, select the other instance as the Other Actor</code>. </picture> </figure> </blockquote> You can subscribe to this blog using any old RSS reader, if it tickles your fancy to follow along! Just plug https://vikram.codes/blog</code></a> into your RSS reader of choice and it should work. </blockquote>

Vikram Codes

Self-hosting my website

Tech Stack</h2>

Git LFS File Locking

The 3 daily commands</h2> There are three important commands for git:</p>

Agile Spikes

Navigation Filtering and Avoidance - Basic Tag AI in UE4

Gameplay: Tagging Behaviour</h2> Now lets add "tagging" when the "it" bot gets close enough to its target.</p> For the Character, we want to add a couple of bits of game logic:</p> When we are "it" and a "not-it" Character is in range, "tag" the target</li>

Wrapping up</h2> Now you know how to set up Navigation Filtering, how to get your AI to avoid each other, and hopefully have learned a little bit about best practices in UE4!</p>

Navigation Modifiers and Links in UE4

Nav Link Basics</h2> Our next challenge is to add the ability for the AI to "drop" from one part of the NavMesh to another part, without having to go around.</p>

Wrapping up</h2> Now you know how to modify the Nav Mesh to make it as accessible, or inaccessible, as you would like!</p>

Basic Navigation in UE4