next »

[nathy after dark]

Camusos. (Cah-moo-yos)

[bryku]

That rat sprite looks glorious.

Thanks - all the credits go to Kurt who is doing the graphics!

Camusos. (Cah-moo-yos)

I couldn’t have put it better myself

[bryku]

June progress summary, part 2: AI behavior

So another thing I did work on in June was making sure that enemy characters finally start behaving in an interesting way.

Due to the cover system that the whole combat is based on, AI needs to be aware of its environment and perform an action which seems to be the best one (well, maybe not always best for them - to make sure that the player gets some fun out of the combat as well).

The way I implemented it was to make sure that each AI character has all the necessary information available when determining their next action. By "necessary information" I mean things like: potential cover locations, targets and threats, amount of ammunition available, etc.

Then, based on this information, the AI can evaluate its possibilities by taking into consideration all the positive (e.g. option to flank the player) and negative (e.g. option to become flanked) aspects.

I have only implemented few basic behaviors for the AI, so far which include:

• Always take a shot if the enemy is flanked,
• Look for a cover that allows you to target the enemy with the biggest % to hit,
• Reload your weapon if you are out of ammo,
• Make sure that the cover you choose does not require a full move (as that will allow you to perform a shot).

As you can see there is no melee combat related behavior here as of yet.

Now, even if in most of the cases the AI seems to be behaving quite nicely:


It turns out that sometime they have issues with determining the best cover:


Now, in theory all is correct here: the AI has chosen a location where:

• They have full cover (well, they do stand near a solid wall)
• Player characters are not flanking them.

On the other hand, it seems that in such situation the ai should in fact be flanked be player characters.

I definitely need to investigate this further, I guess.

[bryku]

June progress summary, part 3: Armor, shredding, and messages' display in general

Hello again and welcome to another part of the summary of stuff that I managed to implement in the previous month!

Armor mechanics is pretty straightforward: aside from having regular hit points, each character can have armor points defined (displayed as an orange rectangle, alongside of hit points). Each armor point reduces the damage taken by one. The armor can be shredded using specific kinds of attacks.

Now, the key was to make sure that information about damage absorption and potential armor shredding would be clearly displayed to the user - so again, I re-used the approach from xcom:



As you can see, each combat message has an icon and color associated with them. I decided to do something similar:

Here the enemy does not take any damage, due to high absorption.


In this scenario the attack actually shredded 1 point of armor, thus allowing the enemy to take 1 HP of damage.


The combat messages are not limited to displaying damage or armor things - basically all important situations can be described by them:


The same combat messages mechanism has been used when displaying the overwatch reaction shots, which I will describe in the June summary tomorrow.

Cheers!

[bryku]

June progress summary, part 4: Overwatch mechanism


The idea is simple - a character can spend their action on entering an "overwatch" mode. During that mode, if an enemy moves within the line of sight of such character, the character will get a free reaction shot.

Such shot is occupied with an aim penalty, to avoid situations in which the players would stop actively pursuing flanking and always use overwatch.

Anyway, implementation of this scenario has proven to be a challenge, due to the way I was treating character movement animations: previously I assumed that character movement operation is atomic - meaning that nothing can interrupt it.

With the overwatch mechanics kicking in, in turned out that not only movement can be interrupted, but the character being moved might actually end up killed. As a result I had to tweak the movement and attack calculation logic a little.


Long story short, I managed to get the overwatch mechanics to work, and characters are able to take reaction shots now:


Above is the standard scenario for using overwatch action: you flank the enemy to flush them, and then toggle the overwatch to hit them in their turn.
Of course in this example I could fire immediately with my first character after I moved to the flanking position.

Usage of overwatch will have to be incorporated into one of possible AI behaviors, but that is something for the future to work on.

[bryku]

July progress, week 1

Hi - no major update this week; I am working on enemy pod activation mechanism, and all stuff related with it (e.g. line-of-sight algorithms).

But as I know you guys like gif, here's a melee attack animation of the Rat Grunt (created, as usual, by Kurt):

[TonyManfredonia]

I think your personal vision / goals for the game to make it unique is marvelous. You’re on a great path to success with this momentum!

[bryku]

I think your personal vision / goals for the game to make it unique is marvelous. You’re on a great path to success with this momentum!

Thanks for the good words! The success will be met, though it will take time. The key lies in persistence

[bryku]

July progress, week 2 (part 1 of 2)

Hello everyone! Progress has been made, and it's time to brag.

As I mentioned before, I was working on the enemy pod activation mechanism. I will post more details about it in a few days however, as the first thing that had to be finished is the line of sight mechanism.

Basically there was no such mechanism in place until now. The player always saw the whole map. That had to be changed somehow.

Now, XCom used the standard fog of war implementation - basically each map tile can be:

• Unknown (which then is basically invisible)
• Uncovered, and observed at the moment a.k.a visible (the player has full information about what is going on on the tile)
• Uncovered, but not observed at the moment (the player can "see" the tile, but has no information about enemies on it)

   
I have decided to use similar yet simplified solution, which only uses two of the states above: unknown and visible. This means that after the player uncovers a tile, they get full information about its content until the end of the combat.

Anyway, the technical implementation of  field of view calculation was not that difficult - doing 360 degree raycasts worked like a charm, and didn't influence the performance at all (possibly the fact that the game is turn-based did help here significantly).



The hidden tiles simply had a darker color applied to their sprite renderers. However, I did want to make the fog of war to be displayed in a smoother way. Google mentioned that one can use the approach with rendering stuff to texture, and applying an extra layer on top of the displayed stuff.

In the end I started using the SpriteLightKit library for this, and I ended up with this effect:


   
Although it is still far from perfect, it looks more pixelated.
   
Now, firing the raycasts from the current player location was not enough - because the assumption is that characters can lean out of covers, effectively seeing more.

See the screenshot below - the character should see the stuff on the right, behind the pillar:



I have altered this as well so that stuff visible after potential leaning out is also visible to the player. It is possible that the player is seeing a little bit too much (not sure whether the tile to the right of the rightmost pillar should be visible), but that's desired:




Anyway, this concludes the part about field of view. Next time I will show you how I have used it in the enemy pod activation mechanics.

Take care!

[bryku]

July progress, week 2 (part 2 of 2): enemy pod activation mechanism

OK then, so it's time to be activating these enemy pods!

The idea behind this is making sure that the enemies that are being encountered are spawning in groups, to increase the challenge for the player.

A map can have multiple spawn points for enemy groups (a.k.a. pods). During map generation, a group of enemy characters appears in the close area of the spawn point.

The spawn point can have various parameters, like the number of enemies or their tiers, but that is time for another story. What is important right now is that I can define where a pod spawn location is defined on a map.


Yes, I do have a level editor! And the spawn points are displayed in yellow.

Now, spawned enemies are "sleeping" - meaning that they do not move around the map nor take any combat actions.

The player needs to awake (or trigger) them first - and this happens when an enemy enters the line of sight of the player. And it is only then when the enemy characters get revealed.


Player triggers a pod. Watch all them ratmen go!

Directly after a pod has been triggered, all of its members are receiving a free move, in which they can only take non-offensive actions. In practice it means that they will try to take cover.

After such free move, the player can proceed with their turn (assuming there are still some actions that can be performed).


Another approach of triggering a pod in the same location. Note that the initial positions of the enemies in a pod can change.
Also note that the enemies are only aware of the player character who triggered the pod - that is why one of them actually made a sub-optimal decision to move to a flanked position (as he was not aware of the other player character).

So this is basically how enemy triggering works. The interesting thing about this is that even if only one of the enemies in a pod has sighted the player, all the enemies from the pod become active. It is because I really want to throw the whole group of them on the player. Otherwise it would have been too easy, just picking them up one by one.

So that's all about the enemy pods. I am focusing on some UI things next (movement range display, to be more specific) and then I am moving to the loot mechanics.

Take care!

[bryku]

July progress, week 3

Hello again! This week I am bringing you the revamped character movement range display:


Movement in green area allows the user to perform an action after the move; moving into red area prevents executing any other actions.

Now, I will be sure whether such way of presenting stuff is readable after I will have the "real" floor and wall images - because only then I will be able to see how they blend in with the colors.

Additionally, I've added few more AI changes to the basic rat grunt enemy - it now has only a single crossbow shot available, and then relies on its melee attack. Also, as it will come in large numbers, it is quite easy to kill - so it has only a single HP.


Rat grunt performing its melee attack.

The best part about being overwhelmed by multiple enemies is of course being able to perform some kind of area of effect attack. Even though I do not have a separate animation prepared for this, the mechanics are all there - so it is possible to cause damage on more than one enemy at a time.


Rogue character performing the "ground slam" attack. This attack type will be later on assigned to another character type.


I have now started working on the next major feature, which is the loot system in general. However, due to a holiday break, I am pretty sure that the next big update will come no sooner than in three weeks.

And for the time being enjoy the gifs and be well!

[TonyManfredonia]

I like the Green/Red system. It works well, and would be easy to give a basic instruction during the first “battle” as to how it works. The only food for thought is the immediate, human-engrained thought that Red means “No.” Players *might* assume that they can’t walk in that area from the get go. Maybe there’s a way to grey-out the surrounding area to make it obvious that the green/red are applicable locations to move (if that makes sense).

Again, just food for thought! I think it could work either way

[Josh Bossie]

I also like the color system, but you might want to make those 'action pips' a bit more obvious. Maybe above the health instead of below it?

Actually, come to think of it how will this integrate with your fog of war system? Or will you always be able to see terrain?

[SeanNoonan]

I'm going to be watching this one! 

[bryku]

Thanks for the input, everyone!

I like the Green/Red system. It works well, and would be easy to give a basic instruction during the first “battle” as to how it works. The only food for thought is the immediate, human-engrained thought that Red means “No.” Players *might* assume that they can’t walk in that area from the get go. Maybe there’s a way to grey-out the surrounding area to make it obvious that the green/red are applicable locations to move (if that makes sense).

Again, just food for thought! I think it could work either way

Yeah, you have a point. I guess the original XCom did use yellow/orange for a reason. I will stick to orange for the time being:

I also like the color system, but you might want to make those 'action pips' a bit more obvious. Maybe above the health instead of below it?

Actually, come to think of it how will this integrate with your fog of war system? Or will you always be able to see terrain?

I went for the 50/50 solution - the player is able to see the static elements of the map right from the beginning, but the enemies are being revealed only when they are in line of sight of any of player characters.

And yeah, the action indicators might have to be revamped, as they are barely visible.

And now off I go on holiday! Will be back in 2 weeks!

[CurryTime]

Now this is cool. As a Skaven fan, I'm delighted to see more humanoid rats creep their way into strategy games (even if they're not playable).

[bryku]

August progress, week 2

Hello everyone! So I am back from my holiday break, and here's some progress on the inventory/loot features that I am working on.

Each character will have the possibility to carry several items - basically the more items you can carry, the more item "slots" a person can have. Items of the same type will not stack in the same slot - each item will simply take one slot.

Now, there will be following item types available (at least for now):
   • Weapon ammo clips,
   • Medkits,
   • Supplies,
   • Crystals,
   • Medical Supplies.



I'm switching the active character, and their inventories are displayed. Inventory items are using my temporary graphics, sorry...

Ammo clips will be used for well... reloading your weapon. Note that after you reload a weapon, its ammo is reset to maximum value, but the clip is lost, along with any ammo that was left in the weapon. This will encourage the players not to overuse the "Reload" action, as there will be no benefit for reloading the weapon if there is still any ammo in it.

I will write more about the rest of item types later on. For now, the most important thing is that the player will need to collect most of these items during combat - either from the fallen enemies or by searching for them in marked locations.

I thought about how to implement the UI for picking up/dropping items. Initially I thought about using the approach from classic UFO: Enemy Unknown, or the way that Phoenix Point has it implemented::




The problem with these approaches is that each time the player wants to pick up/drop the stuff, they need to open a modal screen, and spend time there shuffling stuff around.

I don't want such experience to be present in the game. The player should be able to quickly pick up the stuff from the ground and then, if it turns out that they are carrying too much, to quickly drop excessive items.

Therefore, loot pickup mechanism works as follows:
   • Character stands on a tile with loot,
   • Player executes the "pick up loot" action (such action does not cost an Action Point),
   • All items present on the ground are picked up and added to character's inventory; player can immediately see them there,
   • If it turns out that character is carrying too much, the excessive items would be displayed in red,
   • Player can click on any item to drop it.

Below you can see a character carrying seven items, although inventory capacity is four:
   


Oh, and when a character is overburdened, they cannot move nor execute any other actions.

I do need to consider whether it would make sense to implement items' throwing mechanism into the game. After all, it would be interesting if a character could throw an ammo clip to another one. Question is whether that would be fun. We'll see.

That's it for now. Still a lot of work is to be done on the loot/inventory system, so expect that next week update will still be about covering the remaining stuff. I just need to get myself up to speed after the holiday

Take care!

[bryku]

August progress, week 3

OK, I know you guys love gifs and screenshots! So let's make the introduction short this time.

I was finalizing the inventory/loot features. Here goes:


Clicking the inventory item drops it into the ground. Then all dropped items can be grabbed again, using a free action.



When an enemy dies, they might drop loot that can be picked up.


There are "loot points" (next to crates, desks, etc.) being generated on the map, that allow the player to search through them; player might find stuff there.


Player who carries too much stuff gets overburdened, meaning that they cannot move.

I do need to change the loot indicator on the map, but that will become a thing after the graphics for the tiles will be ready - and that is what Kurt is working on at the moment.

And as for next week plans, I want to work on some technical stuff, including moving pieces of gameplay logic configuration to external files.

And yeah, I believe that I need to find a proper name for the game as well. Hopefully I'll be able to come up with something good


That's it for now though, take care!

[nathy after dark]

I saw this in the New Yorker and thought it was too hilarious not to pass along: Rats!

Edit: I can just imagine the rat defense force's funding (through civilian taxes) being contested by the aristocracy as they scapegoat the exterminators for causing their own plague. Lol, ratpitalism, anyone?

[bryku]

I saw this in the New Yorker and thought it was too hilarious not to pass along: Rats!

Edit: I can just imagine the rat defense force's funding (through civilian taxes) being contested by the aristocracy as they scapegoat the exterminators for causing their own plague. Lol, ratpitalism, anyone?

It is surely not easy to fight rats (didn't have this problem myself, but I did struggle with mice). Imagine fighting them when they're your size, and carry knives - you better come prepared!