Author: foufy

Update

November 22, 2023 / / 0 Comments

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!

Godot 4

February 15, 2023 / / 0 Comments

With the release of Godot 4, my previous issues with Godot have been relieved (Mostly some odd crashes related to C#).

I did end up porting a good chunk of the game over to Unity in the meantime — which led to a lot of refactoring and cleaning up of existing code.

But since Godot 4 which is currently on the horizon (release candidate 2 was just released as of this post). I’ve been over the past few months porting the re-factored version from Unity back to Godot 4. So essentially I went from Godot 3 -> Unity -> Godot 4.

This may seem like it was a waste of time but I have been working on new features still such as procedural dungeon room generation, and all the game engine changes has caused a lot of refactoring which in turn has cleaned up a lot of code – a nice bonus! To me, Godot’s workflow is much more enjoyable compared to Unity and therefore worth it to me to port back over.

As of this post, everything has been transferred over to Godot 4 and I hope to soon show some pictures of randomly generated dungeons.

Tweening

January 23, 2023 / / 0 Comments

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?

August 31, 2022 / / 0 Comments

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!

Porting to Unity … continued!

May 17, 2022 / / 0 Comments

Work continues on the porting over to the Unity engine. It’s practically almost all ported over. Most of the stuff that hasn’t been ported over yet includes things such as certain UI elements which I am planning to revamp, some usable skills I still need to port over, and some combat animations. I have actually implemented a couple things that did not exist in the previous version, such as synchronizing character equipment to multiple clients.

Getting quite close to strictly working on new features, which is very exciting. Hope to show off some more soon!

Porting to Unity

April 9, 2022 / / 0 Comments

As you can tell from the title, porting still continues from Godot.

I’ve gotten all the networking and steam integration code ported over, and just recently got zone management working inside Unity. The porting is going well so far and Unity has been quite easy to work with.

In my last post I mentioned how Unity has no notion of separate worlds with their own objects like Godot does. Porting my code that dealt with separate zone scenes had to be re-worked.

What I ended up doing was sectioning up the Unity game world into chunks of 2000 unit length squares, and associated each one with a 3D index. Each time I wanted to instantiate a zone I would grab one of these chunks that wasn’t being used and load all that zone’s data into it. When a player is teleported to a zone I grab the world zone index of that zone and get the world offset and translate their destination location by that amount and everything works out. It took a while to get asynchronous loading of the zones in Unity down but I have a good feel for how scene management works in Unity now.

Next, I’m finishing up porting the work on the floor generation for tower floors. It also similar to the zones needed a complete rework because in Godot I took advantage of the separate worlds to make each room in a floor it’s own Godot World and teleported players between them.

Now I’m actually placing the rooms next to each other and the player can physically walk between rooms in a floor instead of teleporting. I’ll be posting about that solution in the future.

Trivo…

March 21, 2022 / / 0 Comments

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.

Entity Synchronization

February 27, 2022 / / 0 Comments

Lately I’ve been tinkering with my in-game tower map user interface, and messing with adding items back in.

With the addition of item drops, syncing item data lead me to re-work how I managed entity synchronization. The original solution was quite naive and always updated clients with full entity data, regardless if that data was identical to the data during the previous server tick.

Now, entities will only transmit data if it needs to be sent, so a stationary entity will not have its transform data sent to clients every tick unless it moves and therefore the transform information changes.

I originally put this work on hold and had planned to re-factor it in the future, but as I started to create the new DroppedItem entity, which would represent an item that has dropped in the game world, I realized that the Item information that the entity held was constantly being sent over to all clients and figured it was about time to re-factor and improve the synchronization code. Now DroppedItems only send information about what items they contain when they are initialized. Subsequent updates about the items it holds only happen if the items themselves change.

Another boon to come from this is a new way for clients to learn about new entities. Originally, as I have mentioned, the server would transmit all data about an entity to all clients, and therefore the clients had enough information to re-create the entity from every entity update from the server.

Now that it only transmits updates about entities, clients would need a way to ask the server for extra information about an entity to initialize it before they can apply the updates to it. So now, instead of always having the data needed to create the entities, if a client gets an update about an entity that does not yet exist on its end yet, it will send a message to the server asking for all information about that entity. Once the server replies, the client will create that entity and then be able to apply any subsequent updates it receives from server entity updates.

I had tinkered around with another solution in where the server would keep track of new players and new entities entering a zone and the server would handle sending the full entity payload to clients that needed it, but I thought clients requesting for that information would be a better and easier solution. I feel like having the server manage it could lead to some desync situations that would be very hard to debug and it also brings down the amount of work the server has to do during its game server tick.

I know I promised a post about the in-game map, and that is still coming. I got distracted with the updates I detailed in this post and still need to polish it up. Hoping to get to that soon as well as a post about item drops when I finish them up.

Trivo Multiplayer

February 11, 2022 / / 0 Comments

When I started working on Trivo, my goal was to make sure that it could be played with friends online.

So I started off with Godot and GDScript and tried to implement their built-in solution which used ENet in the backend.

This worked fine at the start, but did get a little messy. Eventually I rewrote all of my code in C# and decided to ditch the built-in ENet solution for SteamNetworkingSockets.

The main reason I switched to this was because I wanted to take advantage of Steam’s servers to allow players to play with each other without fumbling around attempting to forward the proper ports before they could connect. I feel like most online games nowadays are expected by users to work online without forwarding ports.

So far, everything is working pretty well, I’ve tested with a few friends and it works quite well while being routed through steam servers. I was able to leverage the Steam friends functionality to allow one to join another player through their Steam friend’s list.

I plan to go into more detail about my client / server architecture in a future post, stay tuned.

Entering the Tower…

January 30, 2022 / / 0 Comments

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.