technicjelle

[technicjelle]

Controller-less VR teleportation

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.

We are not entirely sure if this part will remain this way, as the museum really wants the experience to be as purely realistic as possible.

[technicjelle]

Hiya just wanted to say your plane game looks amazing!!! Game dev grad with an aviation hyperfixation here, very excited for where this is going! Good luck ^-^

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!

If you would like to fork the project to really make it something more than just a little five-minute "tech-demo" experience, please feel free to DM me, and we can work something out :)

[technicjelle]

Planes Tower Defence - "Pathfinding"

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...

Source code available here: github.com/TechnicJelle/PlanesTowerDefence

[technicjelle]

Planes Tower Defence Game - Level

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 ;) )

Source code available here: github.com/TechnicJelle/PlanesTowerDefence

[technicjelle]

Custom Android to Arduino Communication

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.

The code of this project is quite horrible, so I'm not publishing it this time. Also because it's basically just two library examples mashed together plus one of my lecture code samples, so hardly any of this is actually my own code.

[technicjelle]

Whizzy Points Along Curve

I made some particles that spin around in a fun way! :D

[technicjelle]

Fireworks Display in C++ with the PixelGameEngine

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:

[technicjelle]

Space Shooter 3DX Updates

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:

[technicjelle]

Enemy AI in my Space Shooter Game

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:

[technicjelle]

Pacman

I made a Pacman!

[technicjelle]

About Me 🇳🇱

Programmer https://github.com/TechnicJelle/

Artist https://artstation.com/TechnicJelle/

Currently studying Game Development

Tagging system:

Main Category

#Art #Code #Physical — For things I made IRL

Project Type

#GameDev #Simulation

Post Type

#How I did a thing — Post describing (part of) a process #Updates — Post giving a status update on a project

Tools

#Blender #Unity #C++ #PixelGameEngine #Arduino #Android

Post Subject

#AI Programming #Networking #Geometry Nodes

Specific Projects

#Space Game 3DX #Planes Tower Defence