🇬🇧🇺🇸 Bi-Weekly Progress #4

Two weeks went by so it's time for a new biweekly post.

They were two interesting weeks for Vuuh, but not so much for my personal projects.

Vuuh

In the past two weeks, the focus at Vuuh, in the development team that I manage, was on recruiting and building some important features needed for some very interesting partnerships.

The recruiting part was hectic: two weeks full of interviews with a lot of candidates. We loosened our requirements a little and started to consider entry level or junior level software developers as well.

This resulted in a big number of candidates in a very short time span, most of them were very passionate about technology, had a very strong algorithmic thinking, huge growth potential and the right attitude (the exact things I am looking for), but the big number of candidates made us have to choose (it was difficult but it was something that had to be done).

We ended up hiring a few new colleagues that are starting end-August or start of September, and so we mark the beginning of the growth period of Vuuh. Scaling will be difficult , and it is scary and exciting at the same time.

Personal projects - game prototype

I started working on a game prototype, something simple and rather generic, with the purpose of experimenting a little with Godot and building something in my spare time (so my coding skills don't rust).

The game is a fantasy based top-down rogue-lite game, where you control a single character and cast spells toward enemies. Very generic. The catch is that the loot consists of elemental shards (the in-game currency) which can be used to craft new spells or upgrade existing ones. The progression system will be based on the spell crafting aspect, and not on leveling up.

The core systems are almost ready:

• casting spells (simple projectile spawning, going in a set direction for X seconds or until it hits something - it can also be another spell projectile, so you could deflect/stop enemy projectiles with your own spells - I thought it would make for a fun mechanic).
• enemies and loot dropping - the AI is missing entirely. All the enemies do right now is moving towards the player at a constant speed. Will tackle the AI sometimes soon, so that they can also cast their own spells and have a more "intelligent" behavior (such as hiding, patrolling, trying to dodge projectiles, etc).
• picking up items
• declarative game content - initially I went for data defined in Godot script, but it became hard to manage, even with 5 spells. The game is supposed to have 35 unique spells, so improving the game content management became a priority early on. I switched to an XML based approach, because of its versatility. The problem was now that Godot's native XML parsing is very limited and very hard to work with, so I created a new flow

Write XML -> convert it to JSON using a Python script -> load the JSON in GDScript and use that data in the game

Not ideal, but works, and it allows me to better iterate and group resources together.

Now, a spell looks like this:

<skill id="fireball" name="Fireball" icon="res://assets/skills/fireball-red-1.png" description="Casts a fireball into the air, dealing [1 x Fire] damage and then applies a burn for 5 seconds">
  <cost mp="10" />
  <cooldown seconds="1" />
  <effect>
    <projectile speed="500">
      <damage type="fire" multiplier="1" />
      <trail color="@red" size="1" />
      <impact color="@red" size="1" speed="200" />
      <explode radius="100" />
      <impact_statuses>
        <status name="Burning" icon="res://assets/skills/fireball-red-1.png" duration="5">
          <effect>
            <dps type="fire" multiplier="0.25" />
          </effect>
          <display>
            <particles  color="@red" emission="50" speed="50" />
          </display>
        </status>
      </impact_statuses>
    </projectile>
  </effect>
</skill>

Initially, the status effects, the projectiles and the skills were stored separately, and the relationships between them was done using unique identifier strings. This old approach came with the disadvantage that the related resources would be scattered all over the game data file, and updating things became very time-consuming.

Right now, with co-located resources, I can see all the code I am interested at once and modify things way easier.

Who said XML is dead? (I did a few times, but for game data it seems that it does the job well).

Next steps

The next two weeks will be composed one week of work and one week of holiday, so not many things will get done.

On the Vuuh aspect, the plan is the same: recruiting and pushing for new features (and bugfixes of course). I need to spend more and more time on planning new things better, as the systems we have increased in complexity and we have multiple sub-systems that need to work properly together. We need to push more in the quality assurance aspect than we are doing right now, and that is definitely one of my main focuses in the near future.

On the personal projects aspects, I plan to implement a few more spell types for my little game (projectile that explodes at a set location, nearby area of effect spells, self cast). Then I want to start writing the AI for enemies and start introducing enemy types (defined in XML as well). My focus on declarative game content is due to the fact that I will want to be able to create content easily, and once I launch the game and people start playing it, to allow modding.

'Till next time!