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.
No active runs
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
