Virion studios devlogs

Blogging stuff about life, projects, etc.
Some devlogs too.
User avatar
Site Admin
Posts: 114
Joined: Wed Oct 10, 2018 3:48 am

Re: Virion studios devlogs

Post by dendiz » Wed Oct 10, 2018 8:18 pm

title: "devlog #11"
date: 2018-05-04

  • unity port
So far I am content with the Game mechanics I've come up with and the prototyping phase is thus over. One thing I can say about Godot is that the editor sucks, so I had to revert to using vim + CLI. Another thing is that GDScript is a nice prototyping script but I can't see myself using it for a complicated project. Mainly due to the missing data structures, lack of libraries, it's simplistic nature and my personal preference for statically typed languages.

So the real product development I've decided to go with my old friend Unity. I'm now in the process of porting and cleaning the code in GDScript. I've managed to get the Player units, unit selection, path finding, map generation, obstacle generation working in a day. The architecture is *way* cleaner and being able to use JetBrains Rider is a great speed up. Here is a screen shot of the current state
tbtd5.png (67.8 KiB) Viewed 102 times

User avatar
Site Admin
Posts: 114
Joined: Wed Oct 10, 2018 3:48 am

Re: Virion studios devlogs

Post by dendiz » Wed Oct 10, 2018 8:27 pm

title: "devlog #12"
date: 2018-05-07

  • map generation
  • movement, path finding
  • loot generation, weapons
ported over the path finding code and map validation. I ran into a stupid typo bug that was
screwing up the lee path expansion matrix code, which took me 2 hours to debug and fix. And
it turned out to be one of those 1 character typos (wrote a y instead of x). This stuff can
be so frustrating sometimes! I also started genericising the names for the in-game components
as the theme is not decided completely yet. So instead of calling a tile "water" I just call
it a "killer" tile as it could be water or it could be fire. I also did JetBrains Rider a favor
and cleared 99% of the warnings and applied it's suggestions. It's annoying to have code
fragments underlined and highlighted. In the prototype move of the behavior and data and logic
code were in the same file, but with unity using the component system it's easy to separate these
so the unit selection and unit movement code went into their own components. It's quite nice
to have a unit class that's pretty short and these types attributes and behaviors in different
components. I have seen a player class in one of the open source rogue-likes that around 5 K lines
of code. I could never wrap my head around it or even manage that much code in a single file.
I also implemented the movement arcs, and the unit selection indication. I refactored some methods
to return game objects (tile processing code) which I later reverted back the base component
class to take better advantage of static typing. It's easy to access the game object on the
component to get another one anyways, so it makes more sense to return the base component.

In the prototype the units were kind of teleport-ed to a location when clicked on them, with a line showing
path it came from. Now I have the units animate tile by tile to their destination. This is a nice
way to reduce the clutter on the map and make the game look more professional. But now I had to
come up with a way to disable the next turn button when a unit is moving. Otherwise if the player
would press the button the enemies would start moving and the game would stop being turn based
but be more real time, and I'm sure it would cause a lot more bugs and complications. The animation
of the units works by calculating the path it will take and queuing these tiles up in the movement
behavior. If the queue is full, it means the unit is moving and the button should be disabled. So
I added a co-routine in the button behavior that checks this for all ally units and adjusts the
button state accordingly. The queue is processed in the Update loop for each unit, so the checks
have to be done in a separate thread. I also added some enemy units, and after the players turn
the enemy units make their move. In the prototype the enemy units were teleporting too, so I
could just process their calculations sequentially and be done with it. Now I have to do the same
checks I did for the "next turn" button for the enemies so that they play one after the other.

I also ported a part of the loot generator for weapons. This part was bugging me in the prototype
as the implementation done by GO was based on a data centered approach you would use in a functional
language and not really OOP. What I have so far is a function that returns a random prefab
from the available weapons, and the code that spawns the player randomizes the weapon parameters
and adds the weapon instance as a child node to the player. I need to get the parameter randomization
code into the loot generator, and add the items to a player inventory. In the unit lab the player will
assign a weapon from the inventory to the player, and the player with spawn with that.

User avatar
Site Admin
Posts: 114
Joined: Wed Oct 10, 2018 3:48 am

Re: Virion studios devlogs

Post by dendiz » Wed Oct 10, 2018 8:28 pm

date: 2018-05-09
title: "devlog #13"

  • AI, movement
  • movement animations
over the last 2 days the AI got a lot of attention. Moving to random tiles with in the range
was annoying anyway so I implemented a target selection algorithm. The basics are the same
for the algorithm I had used in the prototype. Pick the closest building based on euclidean
distance and go towards that. This type of target selection may sometimes lead to what would
seem as non optimal. Such as the case

Code: Select all

. . . . .
1 x . @ .
. x . . .
. x . . .
. x . . .
. . . . .
. . . 2 .

@ = player
1 = target
2 = target
x = blocker
Here the closest target is 1 based on euclidean distance, when in fact the path to that target
is way longer than the path to target 2.

But "optimal" is not what I'm searching for. It's OK to make the game unpredictable at times,
so it doesn't get boring. After the target selection, I added the ability to show a target indication
for enemies. This is actually a 'threat' indication as the attack will happen next turn. The enemies
stay committed to the direction they are attacking if they lock on to a target and will attack
in that direction if they are pushed/pulled or dislodged some other way. I also added the force move
and it's damage effects on the units. I realized that if a weapon can do more than 1 tile force move
the code has to be in the movement class, as the damage effects need to be applied after the animation
to that tile is complete. This lead to the need for separating the movement animation code from the
movement class into a separate component. I also needed to add a "Fly" method that doesn't check if
the path to a target node contains blockers, as I want the unit to crash into the blockers. While at
it I also changed the way the movement animations were done. Previously I was LERP'ing the movement
between the tiles, which lead to a movement that gradually sped up when it was getting near to it's
target. Now I just use a simple method to calculate the amount to move and animate the movement in a
linear fashion, which made the animations look better. The idea is quite simple, I don't know why I
didn't do it in the first place:

Code: Select all

distance = Speed * Time.deltaTime //distance to travel this frame
dir = target.position - my.position
if (dir.magnitude > distance) {
  translate(dir.normalized * distance)
} else {
  my.position = target.position
I also added an in game console, which I use for messages as the unity Debug.Log sucks.

Post Reply