next »

[bryku]

@seras: thanks, trying really hard to keep some momentum! Although I'm having some delay in new graphics. But we'll get there eventually...

Today's update will be about...

Entry/exit points

Idea of the demo mission that I am working on is simple: you squad is dropped in a rat-infested industrial district of the Capitol, and your mission is to scavenge as many resources as possible - and then to evacuate yourselves.

So the team needs to start somewhere on the map, and then make their way to the other part of it, where the evac/exit point.

I didn't want these start/exit locations to be fixed. Therefore, the map has a set of possible locations that can be used either as an entry or an exit point. These are being randomly chosen, with one rule in place: the exit location should be relatively far from the starting location.

Such randomization will mean that even though the demo mission contains a single static map, it is possible to have different walkthroughs due to different start points.

And then of course the enemy pod locations are randomized as well. I mean there's a static list of all possible enemy locations, but when the map is loaded only a part of them is being added.

In the end the maps will be semi-randomly generated (to be more precise, they will be created from smaller building blocks). Right now however I am not putting any effort in this - there are more important issues to address.

So, there's an entry point and an exit point. The gameplay is not purely about reaching from point A to point B though. It is all about collecting stuff. There is a number of randomly generated (well, semi-randomly; they are again predefined, but only a part of them gets added) loot points on the map. The player needs to stand on the loot point and invoke the "search" action:



Now, I was having difficulties to present the information about loot points (and the exit point) to the user. Therefore I decided to use floating markers that point the player in the general direction, and it seems to get the job done:



Remember that I aim to release a tech demo as soon as I flesh out the gameplay and have all the visuals ready (and sound, maybe...?). If you'd like to be informed first-hand about the release consider signing up for a mailing list that I've created.

[bryku]

OK, so the good news is that the game is already playable and fun.

The AI is decent, and not too smart in general - sometimes probably to some poor AI coding, sometimes due to my deliberate efforts to make the AI semi-suicidal at some situations, to let the player take advantage of it.

The mission objective and pacing seem to be correct. Player must reach the extraction point and collect as much resources as possible. Now, there is no strategy layer present right now so collecting these resources is not connected to any other game mechanic. And it won't be - at least not for the sake of the tech demo that I am tring to finish.

The enemies now come in three flavors:
   - Rat grunt: melee-only attacker, which is easy to kill but comes in big numbers,
   - Rat shooter: equipped with a rifle, but still a cannon fodder-type enemy,
   - Rat soldier: equipped with some kind of more powerful weapon, and with armor (1 Armor Point, to be precise).

The pacing works pretty well. Some enemy pods are present on the map right from the start (and the player needs to trigger them), but the real fun comes with dynamic reinforcements, that start to appear more and more often during the run - effectively introducing a nice risk/reward system. You can try to hang around on the map couple of extra turns, but you risk being overwhelmed.

The UI has been slightly remade, to make sure it takes less vertical space:


The bad news is that all the stuff above about fun is purely subjective.

However, I am not worried that much. I am pretty sure that the current game experience is far from complete - as the game still needs:

Graphics: currently I am using two character models (one for Survivors, one for rats). Every character type will have its own model. Also, some animations are still missing, as well as action/inventory item images.

Music and sound: these are non-existent at the moment.

Polish: It is obvious that I won't be able to achieve the AAA level of polish. However I want to make some improvements to how the game looks and plays right now. Examples:

- Map edges. Either I prevent the user from moving camera too far from the map edge (as this uncovers that black area), or I make sure that the visible map is actualy larger than the playable map:



- Smooth display of fog of war (currently it's very rough):


- Adding more of these radio dialogues that display throughout the combat:


- Adding a main menu/pause screens.


So there's still a lot to cover. However, I believe that I'll surely show the game to outside world in 2019.

(and I need a proper game logo, right? Will take care of that too.)

[bryku]

Having updates around end of a working week became kind of tradition, so here goes:

I've spent most of the time altering the AI handling code. When trying to determine their best move, the AI was performing evaluation for every potential map tile that they could reach. It was evaluating potential shoot targets, the ability to flank an enemy or the risks of getting hit/flanked.

However, this was causing performance issues. The part about calculating potential hit targets was pretty heavy and included a lot of raycasting. Now, the issues were not that big (after all, it is a turn-based game) but they were noticeable (the frame rate was tanking for like half a second).

So what I did the other day was reducing the number of potential map tiles that the AI was considering as move targets. I assumed that enemies should not end their turn in coverless positions anyway, so AI started to ignore any map tiles without a cover when perfoming the calculations.

This significantly improved the performance - the framerate stuttering was gone.

However, the melee-only enemies were behaving... not in the way I wanted them to. Basically this enemy type should act suicidal. Their goal should be to run towards an enemy as soon as possible and deal some damage. They should not worry about cover.

In the end I reworked the AI, so that melee-only characters are simply ignoring all the risk/opportunity assesment during their turns, and rush directly to the player:


Rat grunts are rushing at the player, ignoring cover! And that's cool!

[bryku]

This week I managed to work on some polishing. Remember the rough map edges I mentioned two posts again? Well I tried out an approach with a layer of "fake" map tiles and a half-transparent texture and this is how it looks like now:



Additionally, I made some more fixes to the AI - I believe that I finally found an issue which was causing the AI to incorrectly assess potential threats (it was basically ignoring a possibility to become flanked). Of course we're talking about the AI of enemies that are not suicidal by design

What is more, I carefully started to experiment with normal maps. The only light sources in the game are the characters themselves (and I am using the 3/4 perspective) so I decided to apply very soft normal maps to some of the obstacles. It might be that I could be exploiting this feature even more. I just don't have experience with it.



Also - I will have some audio soon. But then I will have to actually incorporate it in game, which will surely be loads of fun.

Take care!

[bryku]

Time to sum up the latest work. First of all, let's revisit the map edges thing. Even though a map has a fixed size, the player is able to see tiles that are outside it:


Now, as you can see it is not possible for the characters to move onto tiles on the left - that is because these are just graphics added artificially.


All the highlighted stuff are not 'real' tiles.

To make sure that these artificial tiles look correctly, I simply am using the nearest  "real" tile type, thus making an impression that the map is longer than its original size. And then I display a semi-transparent image with a gradient on top, to create a fade effect.

Additionally, I modified some of the visuals. I still don't have any new character art/animations ready (hopefully something will come up before end of the year), so I focused on the UI. I made sure that the shield icon for "hunker down" state is more visually distinct. Previously it was using a different color/shadow:



Currently it is having a "plus" sign displayed near to it:



What is more, I spent some time on tweaking the fog of war display. It was pretty rough until now - I simply used a different sprite color on tiles that were unexplored:


I tried different approaches: using shaders, using vertex coloring of a Plane object in Unity - none of them looked correctly.

So I decided to use this small image: (you can barely see it, eh?)

After some rescaling and blurring, it gives a pretty nice effect:


That sums up the progress for this week. I'm attaching an extra gif with a Rogue attacking a rat grunt; I know that there was a similar one the other day, but it still looks cool to me!



Merry Christmas to all of you! I wish you all the best in creating your games!

[bryku]

Aaaah, so the holiday break is finally over! I wasn't able to focus much on the game, asn one needs a break sometimes. You do want to keep your sanity in check and spend some time with family, right?

Nevertheless, there was progress.

First of all, some new graphics arrived from Kurt, meaning that I will be able to incorporate them into the game. Along with these new graphics, a change was made to the rogue character class - she is no longer wielding a pistol, but a shotgun:



The reason behind it was as follows: rogue character should be strong in close range combat; players should want to take risk with moving her closer to enemies in order to eliminate them in a single shot. Now, it was possible when she was using the melee sword attack. However, the pistol that she was holding was not looking as a huge damage dealer. Therefore we have a shotgun.

And yes, I know that xcom's ranger class works very similar (at least in xcom 2). It just seems that this gameplay mechanic makes the most sense if you implement it that way.

I need to re-think my class names, I guess. Other character classes will have more profession-like names (ranger, mechanic, medic). So "rogue" seems to stand out.

Improved crouching

So if a character is hidden behind a low cover, they crouch and have their back touching the cover itself. This turned out to look bad if the character was above/below the cover, so I was simply displaying the "standing" animation that was not really the correct one.



After some changes, the crouching animation looks good on each side of the cover:



Aside from that, I started to work on the main menu screen and making sure that loading of game resources is more clean. There's always that dirty work that has to be done.

[bryku]

Well, premature optimization is the root of all evil, as they say.

It seems that I am not in the "premature" state in the game, as gameplay combat mechanics are already in place. The game seems to be pretty playable but there were significant performance issues - clearly visible FPS drops were happening at given moments. Now, this is not a real-time action game as it is turn-based, but the stutter was real.

Thanks to

I was able to find the source of the problem.

The issue was related to the way in which the AI was calculating the shoot/flanking possibilities - basically I was creating helper GameObject instances over and over again, forcing the garbage collection to perform a lot of stuff inside a single frame.

Man, you really do not have this kind of performance issues when dealing with business software development (which I do for a living)..

Anyways, long story short: the game is now able to maintain more or less stable 60 FPS rate. At least at my machine, that is. I really have to test in on some low-end PC as well.

But let's jump to some stuff that is actually interesting - the visuals!

There is a new evac animation (as usual, all this stuff is created by Kurt Prieto, an amazing pixel artist that I am working with) - meaning that there is finally a visual representation of a character leaving the level:




I also replaced the old "overwatch" indicator icon (which was actually using the same old free asset that I used back when working on the "Twin Demon Slayers" game) with something that makes more sense (an "eye" icon).



See this crystal icon? Well I was previolsly using it as overwatch indicator.

Here's that new "eye" image:



There were also numerous smaller quality of life improvements, like behaviour of the camera in certain cases (it was moving too much) or hiding the action points display of enemies as it did not make any sense to show it anyway.

As the game gets more and more finished, testing all the changes takes more time. I have to perform at least a single test combat run (which can take up to 15 minutes) to see how the changes influenced the overall experience. Luckily, I have others to help me! My son (8 years old), who is a big xcom fan as me, happily playtests the game. This allows me to observe the gameplay from another perspective - so I am just sitting in the back and taking notes of the stuff that needs to be altered/fixed. This is so awesome!



Anyways, the game seems to be getting better and better. At least me and my son are having a blast when playing it, so there's already two satisfied gamers - now that's something!

There's still a long way before the demo is ready. I need more graphics, sound and music (spoiler: all of these are already in production), and of course - a lot of more testing and polish.

But hopefully we will get there, and I will be able to give you some stuff to play with. That would already be a huge success for me - actually finishing something playable.

And here's some more gameplay gifs for you:

Flanked shotgun shot:


Evacuating:


That's it for this week - take care, and have a great weekend everyone!

[Reyn]

You're having performance problems with how many AIs? From your gifs it doesn't seem like you should be having performance issues, If you're using a grid most calculations (including line of sight) should be done with the grid and only involve basic maths, so you would be needing very few raycasts (or none at all), also you shouldn't be instancing GameObjects for AI calcs.

I'm also making a turn based game and my AI checks every reachable tile, every perceived enemy and every ability (1-4 abilities) every turn and the calculations are pretty much instant, heck I can run 20 AI units in real time (think Fallout: Tactics) I execute their AI calculations 10 times per sec and I get around 100FPS on my old FX6300.

Most of what you need to know you can find it here:
https://www.redblobgames.com/

For cheap field of vision algorithms you can go here:
http://www.roguebasin.com/index.php?title=Field_of_Vision
Rogue Basin has a ton of useful information about grid based games.
You can also check this other page:
http://www.adammil.net/blog/v125_Roguelike_Vision_Algorithms.html

For AI you should Google weighted tables and behaviour trees (and maybe goal oriented planning), you'll probably need a mix of those and maybe the blackboard system (I just use lists).

If you want any help you can PM me and I can share my code or check a look at yours.

[bryku]

@Reyn, thanks for that!

Luckily the problem that I was having was not related to an uneffective algorithm (I am using a decent pathfinding and FOV calculations) - it was related to the way I was calculating the ranged attack possibilities.

See, the issue with calculating whether a character can/cannot attack someone does not include regular raycasting from character's position to its target. See this targeting/flanking schema describing how this works in xcom:



The thing is that I need to perform calculations for the potential positions that a character could be at. For attacker, these are the positions on the sides of a high cover - which simulates the character leaning from the cover and making the shot.

Additionally, same works when trying to shoot a character who is hidden behind a high cover - I needed to check whether a hit has been made with any of potential "leaning" positions, and this counts as a hit.

Now, when the AI is determining its next move, it needs to gather information about all the potential threats and opportunities - this includes calculating ranged attack chances.

So basically a character needed an extra instance of a sub-object with collision information - to be able to work with the "leaning" mechanism. And my problem was that during every such check I was creating a new instance of sub-object. With collision information and stuff. And then it was destroyed immediately.

And then this creation/deletion repeated itself.

For. Every. Goddamn. Possible. Location.

So this quickly got out of hand. These short-lived objects were forcing the Garbage Collector to perform a lot of cleaning (note: I am writing this stuff in C#). Profiler in Unity did point me in the correct direction with this, so I was able to fix the issue with reusing the same instance of an object with a collider in every case.

So that's the long story behind performance issue.

I will read the stuff about behaviour trees that you mentioned about - it might come in handy.

Now, what's the progress of the game itself?

First of all, I did some more bughunting and managed to fix issues with calculating hit chances. Again, it was related to the fact that sometimes the attack does not occur from the original position of the attacker, but is about them leaning out of the cover.

See this screen:



Rat is clearly flanked here, however it does not have its cover displayed in yellow (which is used to indicate it being flanked). On the other hand, the player character (wielding this badass shotgun) is flanked. So clearly the calculations were done wrong; anyways, that's fixed now.

The second big thing was allowing some of the movement to be displayed in parallel. So now every time an enemy pod gets revealed, its members are performing their activation move altogether:



Note that this only occurs for the pod activation phase. During normal enemy turns, only a single enemy moves at a time - this is to make sure that the player knows exactly what is going on.

That's it for now. Grab some more screenshots/gameplay gifs:

[nathy after dark]

Weird discovery from my job at the Utah Digital Newspaper archive: What Mrs. Brenninger, of New York, Says about Rat Poison

[Rarykos]

Ah this is coming along so nicely!
I'd love to know more about the world :D
Why rats tho!
Well, I'm glad it's not pigeons

Oh I feel you on that aiming problem.... It's good you caught it before release!
I feel like I run into a few interesting bugs like this in the new XCOM.

[bryku]

Weird discovery from my job at the Utah Digital Newspaper archive: What Mrs. Brenninger, of New York, Says about Rat Poison

Yup, I totally agree! High-end poisons do make sure that the rat becomes sort of mummified. Then it doesnt's smell.

Ah this is coming along so nicely!
I'd love to know more about the world :D
Why rats tho!
Well, I'm glad it's not pigeons

Thanks! I will surely write something more about the lore. I need to flesh out the combat mechanics first.
Not sure what you have agains battle pigeons? Ever played "Enter the Gungeon"?

Well, that's technically a gull, but you know the idea


Why rats? Well, I guess I just like the Skaven guide from Warhammer. And as I didn't want the enemies to be human, and because aliens were already taken, it's rats.



Well, it could also be orcs of some sort - but the rats seem to get with a plague vibe better, right?

Camera effects
Anyways, about the weekly update: I was busy most of the time playing with the camera. I wanted to make sure that shooting animations are reinforced with some camera zooms and shakes, to improve the overall experience.

So I've added some screen shaking during shots:



Same with grenade explosions:



I also added some soft, barely noticeable zoom-in during shooting:



I believe that this is enough for now; and that it is not too much to cause any nausea

Additionally, I have posted my first post on Reddit, on r/IndieGaming. The response and feedback was really great and had built up my confidence that I might be creating something that might be interesting for others as well. It feels great!

Oh, and one of the Reddit comments regarding the gameplay video killed me:

defined as xcom-like
shows two misses in a row in video
Yeah, it checks out


Anyways, I've made some rough roadmap for the upcoming months to make sure that I know what I am working on. Next week will be mainly about fixing any outstanding annoying bugs. This will require a lot of playtesting - so hopefully I will be able to post a lot of nice gameplay videos.

Thanks for reading!

[bryku]

Kickstarter!

No, not for my game - that's waaay to early to even consider that But - a fellow indie developer Jakub Hakiel has just started a Kickstarter campaign for his 2D top-down action rpg named Ada. Go check out his Twitter and the Kickstarter page!

Game progress

Now, about the progress on "This is The End": as I mentioned, I went bughunting again. The fixes were mostly cosmetic, but I managed to remove quite a few annoying ones as well.

I must say I enjoy describing the code check-ins when working on a game in opposite to working on a business application (which is what I do for living for now). I mean business app check-in names are boring! Compare "Fixed a calculation issue for negative gross values" with "Attacker animation now does not freeze while waiting for the target to collapse dead". Now how cool is that?

While working on some fixes I have also altered the way in which the % to hit is displayed: instead of only showing it on the bottom part of the UI, it is now also displayed near the targeted character:


Oh, and when a survivor dies, the camera focuses on the corpse a little longer before moving on to another character. Game will be have permadeath, so I want the player to focus on the death moment a little more.


Anyways, I have managed to remove all the nasty bugs from the gameplay. And from now on I am enforcing a zero-bug policy - meaning that if I find one I will focus on fixing it right away instead of tossing it to the "will fix later" bag. These stabilization/bughunting milestones are simply too boring...

What's coming up next?

I have noticed that I am becoming too obsessed with tiny details of the game (like constantly tweaking the camera movement); my focus must be more about adding all the remaining features. So the next milestone is about altering the demo level and playing with lightning in the game.

Oh, and I am starting to feel that I need a game logo. Gonna have to think about that.

Also, here 's some more in-game screenshots/gifs. Enjoy!

[Ramos]

I swear, in all RPG's I played including fallout, there was always a "kill 10 rats" quest, now I see you are actually making a full-length game with "this rats", kudos on the big eater egg you got here if you did it on purpose.

[bryku]

I swear, in all RPG's I played including fallout, there was always a "kill 10 rats" quest, now I see you are actually making a full-length game with "this rats", kudos on the big eater egg you got here if you did it on purpose.

Haha, I didn't even think about it in this way... you have a point though!

[bryku]

So I told myself that this week will be about creating a new map and experimenting with lighting. And it turned out that it was exactly what I was doing

New map

During playtesting I figured out that the game looks nicer if the combat is oriented horizontally rather than vertically - meaning that the enemies are coming from the left/right instead of top/bottom sides. The player simply needs to zoom out quite a lot if the enemies are far above/below them:



Obviously, as the game plays on a tile-based map, enemies can come from all directions - however, I can control it by creating a map layout that encourages horizontal movement.


There is no way for the player to move too much up/down here nor spot enemies that are above/below them - due to the walls blocking the view. Of course there is still enough space for the player to consider flanking the enemies if necessary.

Lights

So until now the only light sources on a map were characters themselves:


Such approach was better than having no lights on the scene, but was far from perfect - so I decided to remove the character light sources, and start putting lights on random places of a map; that included a flickering light on that 'generator' asset that is currently serving only as a map decoration. And it turned out to look pretty nice:



The other light sources that I added include a small wall lamp, and a... lamp placed directly inside pavement?




I don't fancy the latter, so I am pretty sure it will get replaced with something else. I need a regular lamp post obstacle anyway (as I need more high-cover elements that can be placed on a pavement), so it might be that it will replace that floor lamp later.

New character model

Kurt has finished most of his work on the ranger character assets (kind of a sniper class) which I've incorporated into the game. This has increased the number of character models used in the game by 50% (from 2 to 3) - now that's a progress, isn't it?





Future plans

Now, I might still be spending time playing with tweaking the lighting system - but I don't want to get stuck. So the next thing I will focus on is the UI - so displaying action icons, inventory, character information and so on.

That's it for this week - thanks for reading!

[bryku]

Ah, so I am back from winter holiday. Here's a summary of the new stuff that I managed to put in the game.

UI tweaks

The main goal of the milestone was making the UI look nicer. I made the buttons more round-ish, and reorganized the bottom parts of the screen. One of the major changes was moving the weapon overload warning from the bottom to the top of the screen, and making it more exposed:



The overheating mechanism (that I described in one of my previous entries) turned out to be working just fine, so I decided to keep it. I am planning to dedicate one whole milestone just for fleshing it out in the future.

Also, I was experimenting with making sure that actions are displayed in a distinguishable way, depending on the amount of action points they consume. Tried coloring their backrounds, or changing the color of icons; in the end I simply colored outlines of action buttons.

So free actions are green; blue ones take 1 AP and orange ones: 2 APs. Also, to make the coloring consistent, the movement range is blue for moves that consume a single AP.



I've also added some tooltips for the inventory part.



And that will basically be all the UI stuff that I plan to change right now. I mean I could spend days doing this - but that's a recipe for disaster (i.e. never finishing the game).


New visuals

Now, in order to make the development process more diverse, I started to do some pixel art myself. Started with this Empire logo:



Now, the Empire owns the city in which the game action takes place. I won't be writing too much stuff about the lore yet - time will come for that.

Additionaly, I've made a reskin of the rogue character - so now there are two models available for this character class:



What's next?

First of all, there's a lot of minor issues that need to be addressed (their number never seems to go down...). However, the main focus of the current milestone is to incorporate a bunch of quality of life changes (adding some more gameplay messages, making the enemy pod generation system more fair, etc. etc.). Also - maybe I'll be able to put some new graphics into the game. We'll see.

Bonus

Ah, yes! It was my birthday recently! I mean... almost. I was born on 29th of February, so you get the idea But - I managed to create this cheering rogue animation when practicing my pixel art drawing skills




Thanks for reading! If you'd like to receive more frequent updates about the development, follow me on Twitter at @bryquTheDev.

[bryku]

Hello, world!

Gonna keep the introduction short this week and focus on graphics. You're here for the gifs anyway!

Made the coloring more consistent: movement targets requiring two action points are orange now:



Added some quality of life improvements: for instance, there's a clear indication that overwatch has been removed after a character is hit:



Also, there's an 'evac all' action available, evacuating everyone in the exit area:



I've added some more knockback to the death animations:


(that being said, the death animations might get an overhaul in the near future. Stay tuned!)

As the graphics for ranger character are ready, now there are three character models available:



What's next?
My next milestones are about making the game complete in terms of having a menu and end screen. I started to implement new mission summary screen:



for the reference, this is how the old one looked:



Trying to keep it dark and gloomy. I will incorporate some nice sound effects into it, to make it feel even more that way. But - it is not time for the sounds. Not yet.

Do leave me a comment about what you think of all this - I'd be happy to receive your feedback.

Also, if you'd like to receive more frequent updates about the development, follow me on Twitter at @bryquTheDev.

Thanks for reading!

[bryku]

Howdy!

You know, part of me is hurting due to lack of any feedback on my entries in my devlog. On the other hand, my ego is being partly satisfied by the feedback I receive on Twitter. Also, I believe that (as any devlog, or blog in general) there's a bunch of silent admirers present anyway

Additionally, I simply enjoy spoon-feeding all of you with gifs and images on a weekly basis, so here's some more to share.

First of all - I was working on having a basic main menu of the game.


Tried to keep it to bare minimum. The contrast between "This is The End" and "Start" seems unintentionally funny though. Also, I might need that logo for the game. I keep on repeating this, I know.

Anyways, the main screen is there, the end screen (which I presented the last time) is also present - meaning that the game has a legit start and end (well, at least for the part which will be covered by the tech demo). Also, I moved some code around to make sure that there's a separate place and time for loading game resources. So I have a loading screen, really.

I will still have to implement handling of options and displaying credits. Credits will be one of the last things on my list; options will come in sooner, as soon as I figure out what should appear there. Surely I'd need a brightness slider, two sliders for sound and music volume, and possibly something to handle game resolution change?

Having that part of the game ready, I fleshed out some outstanding annoying issues, like making the movement smoother and slower - especially when dealing with diagonal moves:

(first footage is using the old movement speed; second - the new one)

I still believe I should make sure that movement paths are more fluent; possibly I'll have to use some kind of interpolation when calculating the movement - but I need to watch out for characters going through obstacles/walls, obviously.

Additonaly, I started adding some game lore related stuff into the assets. Here are some Empire conscription posters:



And here's one appearing in the game:


My next milestone was about trying out "character speech bubbles" idea - basically I wanted the survivors to comment on different game situations. The goal is to make them more human and relatable - just to make sure that their inevitable death (game will have permadeath) will affect the players more

Here's how it looks so far:

Character commenting that no enemies have been met in X turns:


Character commenting on another character finding stuff:


What's next?

Well, this is the first time that I am not sure about the priorities.

I need a game website so I might spend time on creating one. Or, I might add myself a Steam page, allowing people to wishlist the game. I heard that it is never too early to start the wishlisting process.

But maybe I'd need that logo first.

Alternatively, there's whole another subject to cover, and these are the sounds. I already did some proof of concept with that and stuff seems to sound great. The problem is that in order to post update on sounds, I'd have to be uploading videos instead of gifs. And in order to do so, I'd have to have a decent... logo of my channel/game? Damn.

Of course there's a bunch of other features that need fleshing out: things like weapon backfire mechanism (which needs more 'live' animations), or the whole character quirks/bounds mechanism (that I haven't mentioned about until now, really).

I guess I will spend the weekend celebrating St. Patrick's day and see what comes into my mind after that

Bonus

I was practicing my pixel art skills again: here's a black mage, made for pixel dailies the other day



Take care, and thanks for reading! As usual, if you'd like to receive more frequent updates about the development, follow me on Twitter at @bryquTheDev.

[ANtY]

A lot of great stuff to see in this thread! I like when the characters in my team comment on what's happening currently in the game and that's something I'll definitely have to add into my project too.