Category: godot

Details about Nebulis Entity

It’s time I start putting out more information about Nebulis Entity – it is a 3D co-op first-person survival space ship crew simulator game. Aboard a spaceship, you perform tasks and maintenance to adventure as far as you possibly can to uncover more about the universe you’re in.

Currently, the basic gameplay loop, as well as a temporary lobby area are done. So essentially you can currently board a space ship, and pilot it through space. If your ship explodes you are sent back to the lobby where you can board another ship and go again. I’m just adding more content and polishing existing systems I’ve created and will be posting images / videos here as I work on different things. To start, here’s a small video of looking out of the ship into space from the crew’s quarters.

I’m currently working on fire spreading system when your ship is damaged – stay tuned for some details about that soon!

Real-time Shadows

So I recently was having issues with low frames per second in my game that I’m currently working on (more posts to follow regarding it).

My game is networked and I’ve crafted a framework on top of Godot & SteamNetworkingSockets, and I assumed that this foundation that I laid my game upon was inefficient and spent about 4-5 nights improving it and trying to make it more efficient.

I made two big changes to my system:

  1. I use MessagePack for data serialization for all network communication. I do this on the main game thread, and I figured I could improve performance by moving this to two separate threads: one for serializing and one for deserializing. This did not take too much effort to get working, also a by-product of doing this work was I moved allI serialization code into only one place in my code, it was a little bit of mess before and now it all happens right when we send/receive network messages.
  2. Networked objects can have attributes on properties so that field or property can be synced between clients, kind of like a network variable. The way I was managing this was quite messy and I had been meaning to more deeply integrate it into MessagePack and streamline it for a while. This work took a great chunk of my time but I’m happy with how it turned out. I essentially went from a weird system where I sent and stored serialized byte[] information with type information that were deserialized on demand. Now I have it setup so MessagePack can deserialize all that information when the network state is received and it’s stored properly in an object variable, ready to be used whenever.

In the end the frames didn’t change all too much, I may have gained 5-10 fps — but it did make me feel happier to have completed the work.

As the title of this post may have foreshadowed, I pretty much doubled my FPS by turning off shadows on my lights in my game. My game doesn’t have that many light sources with shadows enabled – it seems they’re just quite expensive and it drastically increased the draw calls Godot was making (from 8k~ to 2k~ in some instances).

I still wanted shadows on my SpotLight3D’s though, so I ended up learning about Distance Fade, which essentially disables the SpotLight3Ds shadows if they’re not near the active camera. I also adjusted the shadow settings in the Project settings and reduced the quality of them – my game is going for a low polygon look and I think it actually adds to the aesthetic to reduce the shadow quality.

Distance fade property screenshot:

Lights and Shadows properties in the Project Settings:

In the end I’m back to a nice practically constant 120fps and I still have my shadows – and a nice little rewrite of some aging code to boot.

Thanks for reading & until next time.

Nebulis Entity

I know I haven’t posted recently, but progress has not stopped. Well, kind of. The RPG game that I’ve posted about in the past has been put on hold, and I switched gears over these last 3 months to a game with a simpler idea.

I felt that my previous game idea just kept unwinding into a bigger project every day I kept working on it. A lot of progress has been made on it since I last posted, but I thought it’d be good to do something way smaller in scope and then go back to it later.

My new and current project is a 3D game where you and optionally some friends perform research on entities on a space station above a recently discovered planet. I’m nearing a demo-able state of the game and promise to put more information soon. To give you an idea of the aesthetics, here is a photo of a vending machine that you can use to obtain a snack to fuel you during your hard work aboard the space station.

The status screen portion of that vending machine is replaced by a UI when you’re in game.

This game idea may sound complex too but I feel I’ve already gotten more content in this game in 3 months than my previous game, I feel like I’ve defined this game a lot more before starting any development which has helped. Also, there’s not much in terms of combat which I struggled to get feeling right in my RPG game. Anyway, I’ll definitely be putting more posts here soon.

More to follow,

Fouf

Update

It has certainly been a while. I’ve been recently busy with a new job I started earlier this year. Nevertheless, progress has continued on my game, but there has been a lot of changes in the direction which I wasn’t sure how to address so I kept putting off making a new post.

I’m currently working on a dungeon crawler-esque type of game. But I’ve switched to 2D, specifically a top-down game. The biggest reason for this change was issues with getting good animations for 3D models that I made. So I’ve put the 3D game on pause for now, and have been working on this new game in 2D, which I’m still working on in Godot, version 4.2 specifically at the moment.

Below is a quick photo, I’m using a free pixel art asset pack called Pixel Crawler I found on itch.io. I’m not sure if it is temporary or will be what I use in the end, but it looks okay for now.

Essentially you control a mage that crafts spells from ‘spell fragments’, which are these granular components of spells. So you could create a spell that explodes and hurts enemies, or one that pushes enemies away. The system for creating spells is quite complex and I’ll be showcasing some of it in future posts.

I’m thinking it will be called Nebulis but I haven’t settled a name just yet.

More to follow!

Tweening

I just wanted to take a moment to write about one of my new favourite features of Godot 4.

Tweening! Now this existed in older versions of Godot, but you had to instance a ‘tween’ node in your scene and then reference it through code to get your tween to work.

For those un-aware, a tween in a video development context is to essentially smoothly move a property from one value to another. For example, say you want to make some text fade in, you could tween the alpha channel of that text from 0 to 1 over the course of say a second.

In Godot 4, they made this much easier to do by creating a new helper function called ‘CreateTween’ off of the Scene tree, so you can do things such as…

Tween tween = GetTree().CreateTween();
tween.TweenProperty(this, "modulate", new Color(1, 1, 1, 1), 0.1f);

This would (assuming that the alpha was set to 0 at the beginning) fade in the object over the course of 0.1 seconds. You can chain properties too, like this:

tween.TweenProperty(this, "scale", new Vector3(2, 2, 2), 1f);

If you add that line after the previous two, after 0.1 seconds of fading it, it would double in size over the course of 1s by tweening the scale property to (2, 2, 2). You can also tween other things such as methods (for example, you could Tween a call to QueueFree() to delete a node after X amount of time!)

There are many examples available on the Godot documentation regarding tweening. There are many ways to customize and tweak how the values transition between values. The change in Godot 4.0 to allow you to quickly and easily create a tween programmatically really reduces to barriers to adding tweens to your game on the fly.

I’ve been using it a lot, especially to give more character to the user interface by making things slightly larger or fading in / out.

Will provide updates about projects I’m currently working on soonTM

Trivo.. 2?

It has been quite some time since my last post. Since then lots of work has happened on Trivo in Unity. I had ported most of the old systems outside of all the old user interface code since that was mostly specific to Godot.

The last thing I worked on was, after getting the A.I behaviour trees working in Unity properly, was messing with Unity’s inverse kinematics with the purpose of moving the character’s palm towards a location to make it look as if they were casting a spell without a dedicated animation for it.

Here is a video below of me experimenting with that:

I was quite happy with the result. I also managed to get tower floors generated out of random rooms with all their doors aligned properly.

But as I continued working in Unity on this project, I felt like I was still so far from my goal and decided to take a step back and go back to Godot 3.5 and create a simpler 2D game. The idea being that I could finish a 2D game in Godot in a short amount of time before going back and continuing work on my 3D game in Unity.

I’ll be posting more about that in the future, but here’s a little spoiler: It’s a top down game where you control a ship!

Until next time!

Trivo…

I haven’t posted recently, and there is a good reason for doing so.

I ran into issues with the Godot engine, I believe I was running into some very odd stack corruption issues where the game would crash with no crash / debug information at all. I tried for about a week to debug it and eventually found that upgrading to Godot 4.0 fixed it. Unfourtunately Godot 4.0 is quite buggy which was really slowing down my progress. I decided to start porting things over to Unity mostly because I was worried of another such bug occurring in Godot 4.0.

So currently, I’m porting things over to the Unity game engine. Which I’m kind of upset to do, since I really do enjoy Godot’s node tree and work flow much more than the Unity equivalents. We’ll see how the next week or so goes as I continue to port over my code, thankfully they both offer C# as a scripting language most of my issues will changing specific Godot specific solutions to Unity.

One example is Unity has no concept of separate worlds which Godot did, so I have to re-work my zone management code to instead instantiate zones in floating sections of space to separate them instead of just being able to create an empty new world for each zone in Godot.

Anyway, I hope to give a update soon about the progress of the port.

Entering the Tower…

I’ve been working on the mechanic for entering the tower so you can start a run in Trivo.

Since the game is being designed with multiplayer in mind, I’ve decided to create a system that allows players to start runs, or to join other on-going runs.

When you go up to the tower to begin, you’ll be prompted by a pop-up window whether you want to start a new run, along with the option of joining any on-going as you can see from the pictures below.

enter tower ui
No active runs
enter tower ui
One active run… by ‘PlayerEntity’

Currently it looks very plain / ugly at the moment. I just got the starting of new runs and the joining of on-going runs done with this very basic looking window. I plan to re-vamp the look now that the functionality is complete and will probably post a picture of the new one in the future.

Tower Floors

My recent game development time has been going towards working on randomized floors that the tower in Trivo is made up of. The idea is, similar to other dungeon crawler like games, that the layout is completely randomized.

The idea for Trivo is that, as you ascend the tower, you go floor by floor. Each floor is composed of randomly arranged rooms. I plan to creates hundreds of these rooms to randomly pick between, along with also randomizing things inside the room such as the types of enemies.

randomized floor layout
A random 35 room floor plan

Above is a “floor plan”, essentially I generate this structure above and note all the dead ends and the starting square.

I use the dead ends to put any special rooms (such as the final room of a floor) that leads to the next floor. So essentially I generate a floor plan like above, pick a random dead end that isn’t too close to the start and mark it as the exit of the floor. I can then use other random dead ends for other special rooms such as a room that may contain no enemies but may contain some treasure for the player.

This is a little sneak peek into the floor generation, and I plan to post more about the actual rooms themselves in the future.

Campfire fire

One of my earlier posts included a campfire, among other light source models.

After importing them into Godot I took advantage of the built in 3D particle emitter and some lighting nodes.

campfire godot scene tree
The campfire Godot node scene, composed of the mesh, particle emitter, and a light source

With a little bit of effort and some messing about with the particle emitter, I got some very basic looking fire that will work well for my use case. Below are a small video of the campfire and a torch.