TechnicJelle

Read more about this move here.

About Me 🇳🇱

Programmer https://github.com/TechnicJelle/

Artist https://artstation.com/TechnicJelle/

Studied game development, looking for gamedev work in The Netherlands

Tagging system:

From here on out, I will NOT be posting my new posts on Tumblr anymore!

I have developed a custom blog site, all for myself:

Please read all further posts there!

You can follow the blog, through the Atom (RSS) feed, so you won't have to lose out on being notified of my new posts!

There are already a few new posts there, and some of my old posts were improved a bit, as well!

We all know the feeling of pure and utter stress when, ten minutes before the deadline, you finally click the Build And Export in your game engine and then it fails to build for some reason.

To prevent issues like this, people invented automated builds, also sometimes referred to as CI/CD.

This is a mechanism that tests the project every single time a change is made (a git commit is pushed, or a Perforce changelist is submitted). Because of this, we very quickly know whenever a change broke the build, which means we can fix it immediately, instead of having to fix it at the end.

It is also useful whenever a regression happens that doesn't break the build. We can go back to a previous build, and see if the issue is there or not. By checking a few builds by way of binary search, we can very quickly pinpoint the exact change that caused the regression. We have used this a few times, in fact. Once, the weaving machines stopped showing up in the build, and with this method, we were able to pinpoint the exact change that caused it, and then we submitted a fix!

It's very useful to have an archive of builds for every change we made to the project.

There are multiple different softwares that do this kind of thing, but Jenkins is by and far the most used. Both by indies, but also large AAA studios! So knowing how it works is very useful, so that's why I picked Jenkins for the job. Again, like with Perforce, it was pretty easy to install!

Here is a list of every build run that Jenkins did, including a neat little graph :)

Configuring it was quite tricky, though. I had to create a console terminal CLI command that makes Unreal Engine build project. Resources used: (one) (two)

It took many days of constant iteration, but in the end, I got it to work very well!

I also wrote some explanations of what Jenkins is and how to use it on the Jenkins pages themselves, for my teammates to read:

Dashboard (The Home Page):

Project Page:

Now, it is of course very useful to build the project and catch errors when they happen, but if no-one looks on the Jenkins page, then no-one will see the status! Even if the website is accessible to everyone, people won't really look there very often. Which kind of makes the whole thing useless… So to solve that issue, I implemented Discord pings! There is a Jenkins plugin that automatically sends messages to a specific Discord channel once the build is done. This lets everyone know when the build succeeded or failed.

We of course already had a discord server that we used to discuss everything in, and to hold out online meetings with. So this #build-status channel fit in perfectly, and it was super helpful in catching and solving issues.

Whenever a build failed, people could click on the link, and see the console output that Unreal Engine gave during the build, so we could instantly see where the issue was coming from. And because it rebuilds for every change that is made, we know for certain that the issue can only have come from the change that was just made! This meant that keeping every change small, made it easier to find and fix problems!

Whenever a build succeeds, it gets stored on the server, in the build archive.

But storing it on the server alone is nice and all, but people can't really do anything with them there. I could personally access them by remotely connecting to the server, but I cannot make my teammates go through all that. So I needed to make them more accessible for the whole team, to download whenever they please.

For this, I wanted to create a small website, from which they can download them. Just by going to the link, they could scroll through every build and download it immediately.

I already knew of multiple ways of easily doing this, so I tried out a few.

The Python programming language actually ships with a built-in webserver module that can be used very easily with a single command. But Python wasn't installed, and installing Python on Windows is kind of annoying, so I wanted something else. Something simpler.

I often use the program "darkhttpd" whenever I want a simple webserver, so I tried to download that, but I couldn't get it to work on Windows. Seems like it only really supports Linux…

So I went looking for other, single-executable, webserver programs that do support Windows.

And so I stumbled on "caddy". I'd actually heard of it before, but never used it, as I never had a need for it before then. For actual full websites, I've always used nginx. After some time of looking at the official documentation of caddy's various configuration file formats and command-line arguments, and tweaking things, I had it working like I wanted! It now even automatically starts when the computer boots up, which is something that Perforce and Jenkins set up automatically. Resources used: (one) (two) (three) (four)

And I think that's it! Unfortunately, none of this will roll over to the next team that has to work on this project, because none of this is code that is inside our project folder.

Here’s a summary of the setup, drawn as a network map:

Future

Working together on a game is quite difficult. How do you make sure everyone is on the same page?

You could send zips with assets and code between people, but that is slow, cumbersome, and very error-prone.

This is why Source Control software was invented. With Source Control, you can store the project files on a server, and everyone who wants to work on the project files, can download the project from the server. Once they're done with their changes, they send them back to the server. Then the other people can get those changes from the server again.

There are many different Source Control softwares. Probably the best-known one is git. (Source Control, Version Control, Revision Control all mean essentially the same thing.) Git is very good for working on projects that are all just plain-text code. However, it kind of falls flat when it needs to deal with binary assets, like textures, models, and sounds. Unreal Engine Scenes and Blueprints are also binary files. So if you don't use C++, but only Blueprints, basically your entire project is binary files.

This is why I went looking for a different Version Control Software that can handle this better. At my internship, I used Subversion, which is said to work better with binary assets, but in my experience then, it still wasn't exactly great. Though that might also have been due to the fact that they barely used any of its fancier features there.

Unreal Engine itself recommends using Perforce Helix Core. (Perforce is the company, Helix Core is the VCS, but the term "Perforce" is usually used to refer to the VCS itself, due to historical reasons. Source) So I looked into it, and indeed, it seemed very suitable!

So we requested a computer from the XR Lab to use as server for this project, and I installed the Helix Core Server on it.

It was surprisingly easy to install!

I then downloaded the Helix Core Client application on my laptop, and connected to the server. The setup there took a while, because there was a lot to learn. But in the end, I did it!

Sadly, Perforce is not free, so we are forced to use the free version, which is limited to a maximum of five users. We are with ten people, so we had to choose a few "representatives" who would actually put the things everyone made into the project. We requested an educational licence from Saxion, but got told to wait. Now that the project is over, we still don't have it. We also requested an educational licence from Perforce itself, directly, but we have still not got a response. But we made do with the limitations we got.

I wrote a guide for my teammates on how to set up a workspace for the project with Perforce, and improved it multiple times based on user testing and feedback. (I sat next to my teammates while they were following the guide and tried my best to now say anything; to let the guide speak for itself. I would then take note of what went wrong and improved that section of the guide for the next user test.)

These are a few excerpts from a recording of the first time I managed to get the experience running on the standalone VR headset.

For my study, I am currently working with a team of other students on a VR experience for a local museum.

The museum plans to have a VR headset somewhere, which visitors can put on to experience how life was like in the past.

There are lots of things to show, so the user needs some way to move from one place to another.

Sometimes, this is done with a Controller, where the user can move the joystick, which moves the camera around the virtual world.

This has a big problem, however: such smooth movement in VR is incredibly nauseating for people who are not accustomed to it, which is definitely most museum visitors.

As such, game designers in the past invented the now common mechanic of teleportation. You point the controller somewhere, click a button, and you get teleported to where you were pointing. The range is usually not very large, to keep it balanced. I have also seen a slightly different mechanic in some VR games, where there isn't a button to teleport, but it is the joystick. You point the joystick somewhere, and you can choose which direction you want to end up in after the teleport.

The concern is that this can be a bit tricky to learn how to do.

Especially if we decide to not use any controllers. To keep things simpler, we would like to not need controllers. Putting on the headset is already complicated enough, and we need to keep this experience as accessible as possible. Controllers can also get stolen or damaged.

Luckily, there are ways to do this teleportation with hand gestures only!

However, these gestures are even more complicated than the controller buttons for it.

So we racked our brains over a really nice way to handle moving around the environment.

Finally, I had an idea!

We can designate specific Points Of Interest in the environment, which will be the only places the user can be at. Then to move from one POI to the other, the user can just look over to such a POI, and they will teleport to it.

Of course, that teleportation should not be instant, otherwise that will still be confusing and disorienting.

So if the user looks at a POI, a small animation will play in front of them to show that something will happen shortly. (If they look away again, the countdown and whole teleportation process will be cancelled, naturally. They really need to stare at the POI for a solid few seconds, to make sure they really want to do it.)

After that animation finishes playing, the screen will fade to black and back. During the darkness, the user will have been teleported. The teleportation is not instant, again, to prevent disorienting the user.

I mocked up a small visual example of how this system could look like in Blender, and showed it to my team. They unanimously agreed with the system! 🥳

Here is that animation:

You will see that the Points Of Interest are marked with blue holograms, which become taller if the user looks near them.

Hi there! Thank you so much for your interest in my little project!

Though I must admit the game will probably never be developed further than what it is currently...

It was made for a university assignment, and that is now over.

The game is completely open source, on my GitHub, so you can download the code and play and modify it as much as you'd like!

You can also play it right in your browser!

In the last post, I wrote about the creation of the level, so now in this one, I'll be writing about how I prepared for the "pathfinding" for the enemies.

On each corner and split in the road, I placed an Empty game object. This is an object that has no information about anything, except for its own position, so they're a very nice base to work off of.

I placed all the Empty route points in a group called "Route" and named them:

Then I wrote a script for the Route, that draws a little sphere and a label for the name around each node, but only when I'm editing the level; when the game is exported, it doesn't do anything.

To have a nice base to pathfind on, we need what is called a Node Tree, which is simply a network of linked nodes. So I had to link each node to the next one. There aren't too many nodes here, so I could totally have done this by hand. That wouldn't be any fun, though, so I wrote another script that automatically links nodes together!

This script loops through all the Empties, and makes them check all other Empties. If there's an Empty to the right or to the bottom of this, we link that one as being a possible next node in the tree.

Due to the way I laid out this level, there are a couple nodes in this network that either have dead ends (10 and 13), or neighbours that shouldn't actually be connected (5 and 16). So those nodes, I set up manually, but the other ones all connect themselves automatically!

The Route Nodes then draw little debug arrows, so we can easily see which nodes point to which other nodes.

Node trees usually don't have directional links, like I have here (as you can see by the arrows). Instead of having directional links, they just throw all nodes into one big, fully interconnected tree, and use a proper pathfinding algorithm like A* ("a star") to calculate the best route to get from one point to another. A* is used in many, many games, due to its versatility and relatively accurate and speedy performance. I've programmed A* before, but I didn't feel like doing it again (because it's kind of annoying) so I went for something simpler for this game.

The enemies in this game don't plan a route beforehand, but instead chooses where to go on the fly: When an enemy arrives at a Route Node, it can see which other Route Nodes this current one connects to, and then just choose one of those as its next destination. As long as all the nodes are connected properly (which you can check by following the arrows), this is a fine enough method in this case.

The reason this works here, is precisely because my nodes aren't fully interconnected, but have a direction to them. If they weren't directional, the possibility for enemies to get stuck walking in circles would arise (which you can, in fact, sometimes see happening around nodes 10 and 13, where there are arrows one way and the other over the same road)

The way enemies choose their next destination is by looking how often each potential next destination has been visited, and it'll choose the one with the least amount. This means the enemies in this game all choose the least trodden path. I found this a quite elegant solution and in fact I prefer it over just randomly choosing a next destination, as this is surer to evenly distribute enemies over each different route.

So this is the reason why I wrote pathfinding with quotes; it doesn't actually find a path it wants to go along at the start with a proper pathfinding algorithm, but it just chooses between some predefined path segments.

The next post will talk more about the enemies themselves.

As a bonus, here's a video I recorded during this process, when the node linking didn't work all too well yet...

Over the last couple of weeks, I've been working on making a little tower defence game in Unity. Now that I've made quite some progress with the base of the game, I felt like it was time to write a bit about it, so let's go!

In this post, I'll write about the creation of this level:

I started off with finding a good tileset to use. For this game, I wanted to focus on the code and behaviours, instead of on the art. So I found this nice Kenney pack:

So then I got to work importing this into Unity, to make a nice level with these tiles. This is the first time I'm making a 2D game in Unity, so I had to look up how to make tile grids work and found this great tutorial:

I made good use of the auto-tiling feature that Unity provides, so I could just simply draw where I wanted the roads to be, and Unity would then choose exactly which tile of the tileset to put where, so the roads would look nice and connected.

During the process of working with this grid of tiles, I found a strange problem, though. Sometimes there would be small lines where they shouldn't be, as you can see here:

There's just the tiniest line of darker pixels in the green grass. This had me, and my teacher, quite stumped for a while, until we finally figured out that it was due to the specific dimensions of the viewport! It wasn't an even amount of pixels wide by high, so at some rows and columns, the GPU chose wrong which pixels to sample from the tileset texture. So luckily this issue could be solved very easily by just never having a screen with an uneven numbered resolution, which never happens anyway! It just can happen inside the Unity editor.

Next post will be about the "pathfinding" I did. (And you'll also understand then why I'm writing that with quotes ;) )

Today I spent the evening (~6 hours) writing a custom Android app to connect my Arduino to with a custom program for that one too, so I can read and graph the values from its joystick:

No PC required! Just power to the Arduino.

It works over Wi-Fi with Web Sockets, with the phone being the server, and the Arduino being the client.

Over the last couple of days, I've made a simple, little fireworks display:

It was supposed to be a quick project, but the physics were a little different than I usually do, so it took a little longer.

In the past, I've always made my simulations like these in Processing, which is a very, very great tool for learning stuff like this.

Though now I feel like I'm ready for something more advanced, so I'm starting to use the PixelGameEngine for stuff like this, which is a something similar to Processing, but you use C++, instead.

C++ is a programming language just like Processing is, but it's a lot more difficult. The performance advantages of it, however, often outweigh the extra complexity.

So switching to C++ allows me much greater performance and also much more control about what exactly happens everywhere.

In Processing, the simulations typically run at a set frame rate, 60 fps by default.

In the PixelGameEngine, the frame rate is unlocked, meaning that it'll go as fast as possible.

Movement on computers usually goes by displacing a thing by a little bit every amount of time. When that amount of time is constant, like in Processing, this is easy: if we want to move a circle 60 pixels a second, we simply have to move it by 1 pixel per frame.

In the PixelGameEngine this would not work, as the frame rate is not constant: sometimes it's 1000 fps, and at other times it is 3000 fps! (Told you the performance was better ;D )

If we were to move the circle by one pixel every frame, the circle would sometimes move faster than at other times, which is not what we want.

As such, a different way of movement has to be used, and luckily for us, the PixelGameEngine provides the perfect solution for this: delta time!

Delta time is the amount of time that has passed since the last frame was displayed, and we can use this to multiply the speed of the circle with to make the speed constant!

To move something in a way like one would move something in real life, we need a physics system. This is used, so we can apply forces to objects to move them, instead of just saying "the circle moves at 100 pixels per second".

Writing a physics system that takes the delta time into account correctly was surprisingly more difficult than I had anticipated at the start of this project.

I started by implementing a physics system like I was always used to from Processing, learnt from the book The nature of Code, while now trying to always account for the delta time in my calculations: (fElapsedTime is the delta time)

But in the end, I had to give up on that and go for a different way of calculating the delta time into my code...

I was helpfully given a link to this blog that explains a new (to me) way of handling cases like exactly these!

This method, simply put, keeps track of the delta time over a longer amount of time, and if a certain amount of time has passed, let's say a tenth of a second, a new physics calculation is done.

This effectively decouples the rendering and the physics from each other, allowing the physics to run at its own pace, while letting the rendering go at its own breakneck speed.

What that also gives me, is a way to choose how often I want to calculate the next physics step, resulting in a simple way to set how accurate I want the simulation to be!

So I followed the tips from that blog post and implemented them into my simulation and after a bit of work, it all looks as great as it does now :)

So that's it!

You can find the source code for this project here:

Since the last post, I've been hard at work adding more and more features! Mainly the second level and sounds, but there's a lot more that went into it all!

Enemies now have health and can be defeated by bumping into them. I'll add an actual shooting mechanic to both the player and the enemies later. For now, this slightly more crude solution will have to do. The enemies also now have thruster particles of their own, just like the player.

I have added a second level with another completely custom skybox made in Blender! Those top two voronoi textures with the very wide colour ramps together are actually the first level's skybox. It just generates a ton of tiny white dots. There are two layers, because one makes tiny dots and the other makes even more and smaller dots.

The bottom part is two layers of noise, distorting the UV space to generate a warped line going around the skybox. That line is then coloured in by the last colour ramp.

You can go from one level to the other by travelling through a portal that appears once you've defeated all the enemies!

I also added sounds to the player's engine and also the enemies make buzzing sounds. And the game has some nice background music to fill up the empty space!

There's now a pause menu with volume sliders for three different categories of sounds! There is now also a quit button there. That is useful, because before there was no other way to stop the game than to press Alt+F4!

There's now also a bit of a tutorial in the top left that explains what to do:

This tutorial system will be improved later.

I'll be putting this project on hold for a little bit while I work on other projects. Perhaps I'll write about those too! :D

Download the game here:

Today, I felt motivated to make the movement AI for the enemies in my in-development Space Shooter game in Unity.

The last few days, I had already been thinking about how to best approach this, and ultimately I had thought up a system that would use a cone of raycasts as the "eyes" of the enemies. Those would detect the asteroids in front of them and by comparing the results from all the raycasts, it would choose the best direction for it to go.

(Raycasts are basically a ray that you can shoot from one point to another point. That ray can collide with something on its way, and then it can give back information about the position of the hit, the thing it hit etc.)

At first, I just had the enemy (at that point still just a capsule) simply gradually turn towards the player and accelerate forwards

Just simply this was already surprisingly effective at annoying the player, but my goal was something more than this. For one thing, this could very easily get stuck behind asteroids.

So I started working on the raycast system! The enemy would shoot out a ray directly in front of where it's going and checks if it detected a game object that can't be bumped around, like an asteroid. (The Unity RigidBody property "kinematic".) So, if the enemy detected an asteroid in front of it, it would shoot out a cone of rays.

You can see those rays being shot out from the capsule in these images. It's really scanning that asteroid!

The problem with the system I have displayed here is that I hadn't actually thought out how exactly I wanted to make the AI choose which way to go. I had thus far only thought about the raycasting, but not the actual "thought" behind the choosing of the new direction.

I tried a few different systems, but ultimately had to switch gears a bit, because this system still shot out one ray usually and if it hit an asteroid, it would shoot out more. This system proved to not be effective enough, so I had to make it so that it always shot out the whole cone.

As you can see here in this video, the rays all seem to get shot out fine. Except they don't. Which gets more apparent if the amount of rays it shoots out gets turned up:

This had to do with the way I calculated the direction in which to shoot the rays, which at first was this:

And it turned out it had to be this, instead:

I'm not too familiar with how quaternions work exactly yet, but I think it had to do with the rays not taking the rotation on the enemy transform into account correctly. By explicitly doing TransformDirection for each axis, that solved it.

In this video, you can see it finally working correctly!

So with this better system for continuous raycasting, I could continue working on the actual choice of direction!

I tried quite another few different comparison methods, but this is what I ended up going with: The enemy shoots out all the rays first, and if it hits anything, it chooses the direction of the ray that's the furthest point from anything it hit. As such, it can pretty nicely avoid asteroids!

You can see the final result in the video all the way at the top of this post!

You can download this current version of the game here: (builds available for both Windows and Linux)

And you can see the source code here.

By the way, this is what happens if you turn up the amount of rays and the distance between them too much:

I made a Pacman!