Last year, I made a VR game about moving through a level as enemies spawned to a beat. It was an experiment to see whether or not moving a player along automatically would cause any form of motion sickness. It wasn’t the most full-featured thing, but it did prove a point. That said, I wanted to go further with the idea.
This year’s game is a two-level game that expands on the ideas a bit, focusing on a more traditional action game format. In terms of player handling, the weapon system has been improved. You can now eject your magazine at any time and put in a fresh one, allowing for tactical reloads. You now have semi-functioning hands, although no real use for them. And you can now switch weapons. The new gun is an SMG I made.
Switching weapons actually involves putting your hand on different parts of your body and pressing the right grip. My understanding is that Boneworks already had a similar system, so it’s not as novel of an idea as I thought, but my implementation works well enough.
As for the levels themselves: The first level is a standard action level where the player moves through a dance club as enemies spawn around them. There’s a part in the middle of the dance floor where the player stops and enemies spawn around them. They then proceed through an office before eventually ending at the last room. Fairly traditional stuff, mostly there just to keep testing that moving the player along doesn’t cause problems.
The second level is the real stress test. The player is standing on the bed of a pickup truck as it drives through a city. Enemy cars spawn as they chase the player, and the player has to shoot them. The increased speed and turning might cause more problems for players, hence why it makes for a good test bed. Originally, there was going to be a helicopter sequence, but in testing that, the up-and-down motion of it made me feel really unwell.
There’s not really much more to it than that. Feel free to give it a go if you have VR.
The SMG that was made for it will be available for purchase at a later date. I need to fix and improve it a bit. There was also another gun that was cut because my friend couldn’t get it done in time due to personal problems. We will get that one ready at an even later date.
So what’s coming up next? Well, a video about 7DFPS to begin with, which I’m currently starting on. After that, the usual end-of-year blog post where I talk about all the games I’ve been playing.
In the new year, things are going to change a bit. I’m going to stop putting unedited first parts of playthroughs on my gaming YouTube channel. It gets bugger all views, and I want to clean out my folders of videos that I, quite frankly, don’t need. I might do more highlight videos or something, or just change the content of the channel entirely.
Global Game Jam is of course coming up. I might join it, but negotiations with the friend I usually do it with have not gone terribly well. I want to use GB Studio to make something, and he wants to use Godot because he hates anything that isn’t 3D. Despite the fact that Godot’s 3D capabilities are less than satisfactory. But we’ll see. I might be able to compromise.
Next year is going to be a wild time. Cybersurfer needs to start being a lot more playable; early access by next year is a goal for me. But it’s going to be difficult.
As promised, here’s a new demo. It’s quite different from the last. The player now goes along the track automatically instead of being player controlled, and handling has been rebuilt for the 4th time.
And the obvious, a completely new visual style.
No more VRM models, no more green placeholder textures, no weird misaligned textures; the real art style is starting to take shape. There’s still a lot to do, but it’s getting there.
But from a technical perspective, what’s changed?
To begin with, look at these images. Can you see the problem?
The verts are not connected properly. This is a problem with the way I’m handling curved corners. When I manipulate the vertices to raise the sides, these unconnected parts would often cause holes. They were never connected properly. This was a side effect of how I was creating vertices in the first place, where I was getting left and right points and adding everything in between, but in a terrible fashion that involved a ton of lists.
As an additional point, I still needed to subdivide along the length of the track in specific sections.
So I rebuilt the track generation system. This time I decided to cut down the number of arrays managing the vertices on a line-by-line basis based on the length of a section of the spline. This also made it easier to connect it up, as I only had to look at the previous line of the array.
Connecting them up had to be done differently this time as well, so as to avoid those previously mentioned gaps in the mesh.
These images are the new triangle order for connecting these verts properly for subdivisions.
As you can see, it works a lot better. And the point behind this is that if I moved any of these verts up or down, they would still be connected without any gaps.
Added additional resolution along the length in different sections of the track proved to be much easier than anticipated, and the results are fantastic, as you can see. The horizontal resolution is a slight issue, as I can only go up in multiples of 2. In other words, 1, 2, 4, 8, 16, & 32. I cap it at 32, as anything higher would be unnecessarily detailed.
After all of that, I finally got back to making corners.
I quickly decided that trying to append additional mesh on to the sides was not going to work due to the colliders on the sides of the track. But with the new way of generating the mesh, it would not be as much of a headache to manage.
But then I had another idea: what if I used animation curves as data for the curvature for the track, as well as the easing between the flat and raised sections? It took quite a lot of hitting my head against the wall to get it to work, but the final result is extremely functional.
There’s more to talk about in regards to player handling, camera stuff, and so on. But I just want to write a few things on this specific aspect. I’ll be making a more detailed video on it soon, although it might take me a while to finish.
Check out the demo and let me know what you you think.
But with the demo out of the way, what’s next? Easy. More of this. And 7DFPS again.
It’s getting close to that time of year where I have to start planning out what I want to do for that. Except for the part where I’ve had the idea stuck in my head since about February. In short, it’s an expansion on the idea of moving a player through an environment with additional situations on top. Basically, creating a bunch of different scenarios that might be good for VR just to see how well they work.
There’s a lot of prep that needs to be done, a lot of it involving re-doing my previous 7DFPS game’s code to make the gun better to use. And to add a lot more guns. Although I’ll be keeping them one-handed, because two-handed guns in VR are fiddly as fuck unless you have some kind of lightgun that you can put the controllers in, I’d be concerned about the tracking at that point.
That will be available in December, but I’ll probably do a video about it soon after I’m done with the Cybersurfer video.
That’s it for this time. God knows when I’ll make another post, but I’ll see you then.
There’s been quite a long gap since the last one of these. I’ve just been so busy with everything that I haven’t had a chance to sit down and write one of these. Even while I write this, I have tabs open for scripts for at least two videos. Although one of them might appear in this post if I can finish it before this goes up.
With that said, here’s what I’ve been up to.
New Stream Graphics
I decided my stream graphics needed updating, but instead of just opening up Blender and going at it, I decided to spend some time designing my ideas before making them, which I think has led to a much better result than last time.
Let’s start with the game dev scene.
Game Dev – Start Screen
Game Dev – AFK Screen
Game Dev – Cam Screen
Game Dev – End Screen
I’ve gone for a rustic-looking apartment looking over a cityscape. This scene has undergone a couple of reworks and changes since I originally made it. I’m showing its current state here.
Let’s start with the foreground first. There’s a desk with a decent wood material on it, a couple of props, a keyboard and mouse, and a mousepad. The keyboard and mouse models are not mine; I found those on the Internet. However, the textures are mine. It’s a plastic-like material with some grime added on top for believability. The mousepad is the camo pattern I like using, but with some additional texture on top.
There’s a picture of my dog on my desk, of course. And then there’s the two monitors. I made these myself, and they are, in fact, properly 16:9. They also use a plastic material, minus the grime. The screen is an LCD shader mixed with a Holdout shader. The Holdout shader allows the screen to be transparent when rendered, so I can put dynamic objects behind it like animated UI and such. I’ll get to that later.
There’s a brick texture behind the desk. I couldn’t make it as realistic as I would have liked, as it made my performance tank while navigating the scene, which was a real pain. Off to the left is glass, which slightly reflects the inside of the room but mostly just serves as a window to the outside.
Before I get to the outside, here’s the rest of the room you don’t see:
As you can see, there’s a couch and a couple of shelves, along with a carpet and ceiling. I had some ideas about reusing this room with different angles, but it’ll probably require more details if I want to do that.
Now, the outside of the room.
This is a procedural city made with geometry nodes. I followed a tutorial for this as I don’t really know what I’m doing with geo nodes yet. Either way, it’s better than what I was doing before with my shoddily made buildings. The scaling on the buildings is fairly inaccurate, and the glass warps the look of them a bit, but I’m willing to live with it.
Game Dev Cam Screen Example
Here’s the camera scene when all the UI is applied behind the rendered image. I’m pretty bad at making fake UI, but I think this looks OK for now. I might look into actually making a Windows Form application with custom graphics and using that instead. But considering the amount of changes this one scene has had since I made it, I think I’ll just live with it for now.
Overall, I like it, but I think there’s room for improvement. But at the same time, those improvements require me to further develop my own skill set. Plus, the lighting is a bit weird-looking, as the outside lighting doesn’t light up the room enough.
Moving on to the gaming scene now.
Gaming – AFK
Gaming – Cam Screen
Gaming – End
Gaming – Start
I designed this to look like a run-down arcade you might find in a failing shopping centre or motorway service station. Starting with the foreground again, there’s a table with a wood material on it and a brick material under it. The TV is actually the same as in my last layout, but with a Holdout shader on the screen mixed with a glossy shader over it to give it a proper look. There’s a plastic sign next to it with text that changes between scenes.
Behind all that is the rest of the arcade. The red camo material is used for the carpet, with some additional bits to make it look like carpet. And then there’s the cabinets themselves.
I just had to include a Rotaction cabinet, of course. SICKHACKS.root also makes a comeback, as Cybersurfer still doesn’t have an actual name. The other game is Tempo Catastrophe, a parody of the Time Crisis games, which seem to infest every single British arcade. And to top it off, a bog standard claw machine.
The latter of the two aren’t as highly detailed as they’re background objects, but they look decent enough in the final render.
Finally, on the back wall, there’s a text object with an emissive shader that I use as a sign, and an exit door that opens on the ending scene, which is a major light source as all the other lights are turned off.
I feel better about this scene than the game dev one. It’s come together quite well, although it did require a lot more effort with all the additional props needed. If I were going to change one thing, I would probably make it look more rundown, with some added rubbish thrown about. I’m also not too happy with the scaling of the room; it’s pretty bloody massive. Like a Megabowl arcade space, if any of you remember those.
I’m not sure how long these will last, but I think they’re pretty neat. The last layout was used for 2 years; let’s see if this lasts longer.
What’s Going On With CyberSurfer?
Last time I made a video and blog post about Cybersurfer, I mentioned that I was looking into a way to build tracks with the spline tool, and I got something working based on a video I found. Well, after a few months of tweaking and adding to it, hoping it would make it more powerful, I’ve realised that I am being an idiot about it.
The video covers this in more detail, and I would suggest you watch that, but I’ll go over some of the basic points.
Based on the video I found, I was able to make a track that follows the spline with the correct UVs and so on. I looked great. Then I started testing it by adding additional verticality and twisting it around. Like making loops and corkscrews.
This is where shortcomings in both my player code and the track generation became evident. Basically, whenever I would hit a bend on a loop, the player would jitter because of the lack of geometry. And when I hit corkscrews, I had the same issue, along with an additional bug where the player wouldn’t stick to the track in those sections.
Adding additional resolution was possible, but it added it to the whole track. Considering how long it’s intended to be, that might end up being too demanding. So I figured that the best solution would be to increase poly counts, but only in the specific parts where I needed it.
Alongside that, I still want things like tunnels and half-pipes in the level, sometimes going around corners. Again, I need extra geometry for that.
My solution was to subdivide the mesh, although along the width, not the length. I go over it in the video in more detail, but the long and short of it is that although I got the subdivision to work, it was an absolute mess. Furthermore, the idea of making tunnels with it is virtually impossible.
As the code got more complicated, trying to accommodate the idea of adding more vertices to it, it became more difficult to manipulate them.
In the end, I looked at all the code and decided that I needed to rethink it. Here’s a summary of what I’m going to try:
Change how I mark out which part of the track needs additional verts by using knot data instead.
Be able to add additional resolution along the length per section.
Append half-pipe sections onto the edges of the corners instead of manipulating the mesh.
Tunnels and other half-pipe sections might become separate pieces that are attached to the track.
Again, there’s more detail in the video, but this more or less covers everything.
The Godot Video
I finally got around to making a video about my experiences with Godot and the things I like and don’t like about it. I’m not an expert on game engines, so it comes from a place of just spewing out my opinions and thoughts in a very general way.
I’m less critical of Godot, although there are still plenty of things I don’t like. But I did find quite a few things I liked, including specific nodes and example-based documentation.
The video has done a lot better than I was expecting it to, and the feedback I’ve been getting has been fantastic. There are a lot of new things to look at and many things to improve on.
Am I going to use Godot again? Yes.
I have an idea for a project, but I haven’t really had the time to start designing it. But with all these videos out of the way, I should get some time soon. I’m not going to say anything about it until I start making a prototype.
Other Things
I have a new weapon asset. I’m calling it the “Czech 75”, which is a very legally distinct name for a pistol based on a real gun that a character from the anime Gunsmith Cats uses. This is in fact the same pistol from the 7DFPS game, although it has been modified a bit with better topology and several other improvements. And most importantly, it is now textured.
So, here’s a VR-ready pistol that you can put into your games. Enjoy.
In related news, the shotgun asset pack is now permanently discounted. I probably need to improve these ones as well at some point, but I can’t really be arsed. I have far too many things on the go right now.
But I am curious if there’s a demand for more weapons. I should also note that both of these were modelled and rigged by my friend and modified, animated, and textured by me. And half of the money from either of these goes to him. If I make more, I’ll likely have to do it on my own, which means I’ll have to learn more about the creation process. To be fair, as part of my Monday streams, I’m learning various aspects of Blender and trying to create things I haven’t before, which is helping me learn how to do stuff like this on my own instead of having to rely on others.
7DFPS is happening later in the year, so perhaps I’ll use that as an excuse for making more of this stuff.
Again, sorry for the large gap between this post and the last one. I have been very busy. And a new gaming roundup post is in the works, so look forward to that in the near future.
Global Game Jam has come and gone again, and I made another game for it. This year’s theme was “Make Me Laugh”. I spent a good chunk of January learning Godot for this year’s GGJ, and as part of that, I made a quick prototype of a 2-player robot arena game. I made it because my friend and I were discussing the lack of Robot Wars-related games and thought about making one for GGJ.
As it happens, the theme fit quite well with the idea, so we decided to fill it full of ridiculous items instead of robots and hope that it would be funny. We thought it was silly, but when we presented it to the sleep-deprived audience, it didn’t get much of a reaction.
But anyway, here’s an outline of the game. 2-player robot arena. You can choose a character body, which will have a set amount of weapon placement points each. You then pick a weapon, and then you spawn into the arena. The arena is a 20m x 20m area. There’s a pit that can be activated via a button on the wall and a dropzone where random items drop.
Here are the body models. I’m personally quite fond of the man holding axles model, as it is way more horrifying than I expected it to be when I came up with the idea. And I quite like the box, too. But I should probably note that I modelled both of those while my teammate did the cheese and the toilet. But I did the textures for all of them.
With a bit more experience with Godot, development this time around went a lot more smoothly. However, that’s also because I was in charge of the programming for the most part. Not to say that I’m a better programmer than my friend, but more to say that I spent a lot more of my time doing the work.
Either way, I used the C# version of Godot 4.2.1 and found the programming side of things to be OK. But there’s still a lot of issues I have with Godot, predominately the general hierarchy of things. Accessing nodes is the biggest pain in the arse, and prefabs don’t really work in the same way they do in Unity. You can’t drag and drop something from the files into the inspector; you have to load it as a packed scene and then convert it to the correct node. But not every node is accessible through code. If you wanted to instantiate a vehicle body via code, for instance, you couldn’t. Hell, you can’t even access it.
I also had issues getting information on the root node of an object, and for one of the scripts, I ended up using GetParent() five times on one bit of code just to get the name of the player object. However, soon after the event, I remembered that Node Groups existed, and I probably should have used that instead.
But the more pressing issue with Godot is just how buggy some of the node types are. For the game, we heavily relied on the VehicleBody3D node to drive the player models. But for the first few days, the wheels on the player models simply went through the floor, and I couldn’t figure out why. And after researching, it turns out that the node by default doesn’t really work how you’d expect and suffers from many bugs. That said, I did eventually find a post that suggested altering the stiffness of the suspension plus some other values until you got the behaviour you wanted. After about 30 minutes of tweaking the values, I eventually solved the issue.
I have no real complaints about the art side of things; Blender is pretty robust these days, although I did learn that the GPU compute option wasn’t configured correctly, and after fixing that, rendering stuff took literal seconds instead of minutes. What bothers me is that this option was always there, but I hadn’t set it up properly. Considering I upgraded my PC primarily to improve productivity, I wonder if I had checked the right boxes, I could have saved a bit of money.
That’s really it as far as GGJ goes.
As for the new stream layout stuff, I finished greyboxing the gaming part of it, and now I just need to set up the textures. I also need to get started on the game dev scenes and the transition animations for both.
Hopefully, I can get all this sorted out by March. I don’t really want to be working on this instead of playing through Dragon’s Dogma 2. On the gaming side of things, I’m making my way through Infinite Wealth and having a blast. I also gave Graven ago and had mixed feelings about it. Persona 3 Royal and Granblue Fantasy Relink are coming soon, with the former being on Game Pass. Relink is a bit too expensive for me at the moment, so I might wait for a sale.
7DFPS happened again, and I submitted a new game. And this one is better than that god-awful zombie game from last year, I promise.
Making a VR game was easier in some ways than I was expecting, and weirder in some ways. I definitely didn’t like being tied to Unity’s pre-built systems as tightly as I was. That said, although the game isn’t as fully developed as I’d like, it’s definitely an improvement.
I’m not gonna write too much about the game because I made a video about it, along with some other info about stuff I’m working on that I’ve previously written about. Here’s the video:
Plans For 2024
My plans are a bit of a mess for 2024 so far due to some things taking a bit longer to do than I expected. However, for January, my focus is on Global Game Jam, which starts on the 22nd.
Alongside that, I’m working on improving my stream layout with new art and transitions. It’s going to be quite the challenge. But things are looking good so far with some of my early brainstorming.
Beyond that, I’m gonna focus full-time on Cybersurfer. I’m really close to a breakthrough with it, and I can’t wait to get back to it after GGJ. And in regards to game dev, my stream schedule for it is going to change. It’s still going to be on Tuesday, Wednesday, and Thursday, but now I will stream in the evenings as well. It won’t be consistent because of how my evenings can be, but it will give me more time to work on stuff.
The gaming streams are going to change a bit. Alongside my regular playthroughs of games, I’m gonna try doing one-off variety streams with many games. I’m then going to take those streams, cut them up on a per-game basis, and put the videos on YouTube as scheduled releases. Probably just one a week to give me some time to make content. I’m not sure how frequent these streams will be, but I’ve got plenty of weird ass games I want to check out.
A bit of a short one, especially after the bloody long post that the end of year one was. Keep tuned into my Twitch and YouTube channels (Both of them), and I’ll see you guys next time.
