Author: foufy

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.

Godot

Last year I messed around with a game engine called Godot, and enjoyed how simple and lightweight it felt. I’ve used Unity in the past but after trying out Godot I preferred it instead. The way it handles game scenes is great, and I found I could get a lot more done in short amount of time in Godot compared to Unity.

The game is currently being worked on in C#. Initially it was 100% written with GDScript, a scripting language similar to python specific to Godot, but I personally prefer a statically typed language. I got frustrated with GDScript as the project and my scripts got larger and eventually decided to re-write the whole thing strictly in C# which is an option for scripts in Godot. So far, so good.

add new script to node
Attaching a new C# script to a node in Godot

Another goal of the re-write was to leverage a new networking solution (SteamNetworkingSockets) instead of the built in networking provided by Godot which uses ENet. I plan to write more about my networking in the future.

When working in Godot, every game scene is a collection of nodes, which can have nodes as their children. Essentially every scene is just a big tree of nodes.

bundled nodes
The ‘Create New Node’ window in Godot

You can instantiate these scenes easily during run time. For example, I have a player scene, and a game scene. When a player joins, I create a new instance of my player scene and add it to the game scene. Every important part of the game is a scene, which are all just composed of nodes.

In contrast to Unity which has objects which you modify and save as ‘prefabs’ to instantiate later and a entity component system (at least the last time I used it that’s how it worked), Godot felt more intuitive and straight forward. Everything was a node.

For a quick example, in Unity you might have a generic object, and to make it render, you attach a sprite renderer component, in Godot you’d add a Sprite node to your node.

node with a sprite node child
A 2D node with a Sprite node child

Anyway, I’m kind of rambling but basically I enjoyed how Godot worked and for my use case it performs perfectly, and Trivo runs quite smoothly on it so far. I plan to keep using it unless it somehow fails to provide what I need for Trivo. With Godot 4.0 coming soon I’m excited to see all the new changes.

Door Portal… Dortal?

portal
A portal that players can enter in Trivo’s tower

Originally I was going to have doors between the rooms, but I ended up going with this portal like effect, but all the code references still call them ‘Doors’ hence the odd post title.

Essentially when you enter a floor of the tower, the game will randomly generate a bunch of rooms connected by these portals, which the player must clear of enemies before they can ascend to the next floor.

I ended up using the skulls I sculpted in an earlier post to create some dark portals that players will use to move between rooms inside the tower. I’m currently messing with shaders to get a cool portal / dark effect when the portal is active and you can kind of see that above. I’m still tinkering with shaders and the door effect and will be posting more about it in the future.

Godot NodePaths

So recently I’ve been doing the user interface for Trivo, and I had been referencing all the control nodes that I needed by creating string variables and storing the path to them.

This worked, but anytime the scene’s node hierarchy changed, my hard-coded string paths would all be incorrect and have to be updated. This caused changes to the UI to be quite cumbersome since I had to copy new node paths over to my code each time.

I got fed up with the workflow and looked for another way, and I can’t believe it took me this long to figure a cleaner way to manage references to the nodes I want to manipulate in my scripts.

Essentially, Godot has a nice feature that allows you, in the editor, to set a scene’s variable. Godot also features a handy variable type called a NodePath which is just essentially reference to a node in a scene. Combining these two features allows one to easily add NodePaths to your script which you can then set to nodes in your scene that will automatically update even if they’ve been moved.

A picture of the script variables, which you can set to nodes in the scene
The node path selection pop-up in Godot

This is pretty simple, but for whatever reason I never leveraged it until now. Glad I’m using it now though, makes changes to the scene tree much easier when I don’t break all the references in the script.

“Sculpting”

Tried my hand at doing sculpting with Blender. I figured I’d try making a skull for some more creepy areas in the game.

Up until now, I’d been manipulating vertices, edges, and faces manually in Blender to create my models. Doing it this way meant the models I created did not contain many polygons, thus the name ‘low poly’ models.

Sculpting on the other hand is essentially giving broad instructions to areas of the model. So you can select an area and push it inwards and it will make a small dent on the model. Essentially like real sculpting, hence the name. This requires models that contain a bunch of vertices to manipulate.

I created the skull below using a reference image, a sphere packed with a lot of vertices and a bunch of mistakes.

smooth skull
“smooth” skull from sculpting
smooth skull 2
“smooth” skull from behind

Now I want to use this in my games, but it doesn’t really fit too well with all of my other low poly models. So I used a decimate modifier on the model to bring down the poly count in an attempt to bring it into the style of my existing models.

"low poly" skull
decimated “low poly” skull
"low poly" skull 2
decimated “low poly” skull from behind

You can easily make out the individual faces of the skull now, giving it a more low poly look. It still has a lot more polygons than any of my other models, but it does fit a little better compared to before if I do say so myself.

After I tweaked it a bit with the decimate modifier, I decided to add little horns and put the skull on a spike.

Sculpting seems pretty useful, but I think I’d need to take advantage of a tablet and pen to do it properly since all the tools are pressure sensitive. I did the above with mouse and keyboard but it takes a lot of adjusting of the pressure setting on the tools instead of just adjusting the pressure of the pen physically.

Maybe I’ll give it a shot with my tablet and see how it goes and post about it in the future.

Loot!

loot bag 3d model
The loot bag, a screenshot from inside blender

Just a small little post showing a loot bag I made for item drops in Trivo.

These will be used to hold items, which will drop from slain enemies.

The player will be able to interact with these bags and a window will appear showing the items contained in the bag and the option transfer the contents to their own inventory.

Slightly different angle picture

I’m hoping to be able to post pictures of the in-game looting window soon, but I’m currently re-working sections of the in-game user interface. When that’s done I’ll post more about it with pictures.

Lights…?

When I started to work on Trivo, I decided I should probably learn how to do simple 3D models so I could at least learn the general workflow from 3D model creation to being loaded up as a game asset. Even if I didn’t end up making assets that were cut up for production, I figured it’d be valuable experience.

A very low polygon campfire

I eventually started to learn how to do low polygon 3D models in Blender (with the help of Youtube videos), and I must say, I very much enjoy creating 3D models with Blender. It feels pretty good being able to create a 3D model that you can then use in a game, even if it may be just a placeholder asset.

Some sort of metal chandelier with candles

As you can tell from the title, the models I made here give off some source of ‘light’. I was messing with the lighting system in Godot and needed some assets to light up the scene, so I took some time to create these simple models and created scenes of them and a light source to use for Trivo.

A wall torch sconce

I’ve started recently to learn how to do sculpting of 3D models with Blender, but I’m not sure if I’ll end up using it much for my current needs. Low polygon models seem to fit my use case quite well for the moment.

Trivo

Recently, I’ve been working on a game named “Trivo.” (working title)

Game Setting

The game is a 3D over-the-shoulder dungeon crawler/roguelite. It’s set around a tower that seemingly rises beyond what the eye can see, which has drawn adventurers to ascend it for untold riches. A community has formed around the base of the tower which thrives off of the adventuring visitors and curious tourists.


The game is being developed with the Godot game engine, and all the scripting is being done in C#. I plan to make some more detailed posts in the future on why I ended up going with Godot, as well as other posts detailing how I create certain effects and scenes with it.

I’ll also be posting more about Trivo in the future, but for now here’s a quick run animation I created in blender for a dummy model that I’m using while prototyping the game’s mechanics and gameplay loop. This is an older animation but I’ll have more coming soon.