Greetings everyone.
As already said in the topic's title, I have a game more than a year in making, and I finally decided to try and start telling people on the internet about how it's going, yeah.
Sorry for any junky English, feel free to correct me in the comments please.

Here's some of the main features:
Genre: twin-stick shooter + simple automation;
Progression: rogue-lite (but WITHOUT mindless numeric metaprog.) with a simple plot taking place in not so simple universe;
Theme: sci-fi, journey of a solo space miner/craftsman who gets involved in some serious action to be precise;
Visuals: pixel art.
Engine: Godot 3 (for now idk if gonna upgrade at all, but always considering this possibility), 100% GDScript

I'm not so sure what is the best things to put in such introductionary devlog besides these, so from now on I'm going to tell you some more about curent state of the development and the game idea itself.

So, here is a brief summary of a plot: player takes role of a space miner and needs to gather raw material from asteroids while moving through different star systems, then process them in their mobile factory. Processed materials can be sold or used to upgrade your equipment - and you better to do so if you want to stand a chance against your enemies, which are presented as space pirates at start, and later joined by some more organized and misterious forces as you progress further to unveil the mystery about certain gadjet you just found and managed to utilize in order to drastically improve capabilities of all your machinery.

Meet the player! Well, not exactly - rather a concept-arts (followed by current in-game sprite) for their main mean of interaction with the game world - autonomous shuttle capable of two things: gathering raw resources to be processed by factory, as well as defending both it and itself from solo miner's main enemy - pesky space pirates, who were constantly trying to rob you even before events presented in the game.

More than half of the gameplay will consist of you piloting this thing - bringing asteroids to factory and fighting enemies, as well as upgrading it's capabilities for both. The round thingy at the bottom is the aforementioned certain gadget. It called SpARC and I won't tell you more about it in this devlog, instead there will be the whole other one fully dedicated to it - I can only tell you it's pretty (really) important not only for you as a player, but for all your pursuers as well, and maybe even someone else...

And speaking of other half of the gameplay - your factory. For now only it's insides, because I haven't even done concept art for the exterior, but you have to start somewhere, right?)

The same way as SpARС, the factory needs it's own devlog, so for now you can only guess it's mechanichs, at least those ones possible to guess from such a simple view.

To address 10% tag I give as a game completion state at the moment - it doesn't mean I plan to spend another 13.5 (billion, ha-ha) years finishing it. For now the project is somewhere around 50% on the way to a 30-minute playable vertical slice. Than, assuming the slice itself will represent somewhere around one fifth of all content planned, we get 10% of total work done. I can't give any meaningfull scopes for now, but it is planned to have a playable demo by the end of this year.

This post is already way larger than I'd prefer it to be, so I hope it managed to get at least some people interested end read to this point.
I hope to keep posting every week or at least two, thankfully at the moment I have enough interesting things to show, accumulated during the development.
Next devlog is going to be about enemies (some of them), so here's some of the earliest concepts to maybe interest you a bit:

For now tha't all.
Thank you for having a look)

Hi everyone, again.

As was said at the end of the first devlog, today I'll make a post about my vision of enemies in Astefactor, as well as about the current state of this part of the game.

My two main goals regarding the game's combat include two things: diverse, challenging, yet fair enemy behavior, as well as rewarding and deep gear system of the same, if not higher, diversity on the player's side. Of course, everything mentioned needs also to be achievable for a solo developer with my level of skills and resources, so I'll try to balance this out somehow.

There are 3 enemy forces present in a game universe: Space Pirates, Cult of the Light, and, being the object of worship for cultists - certain mysterious creatures that appeared in the cosmos at some point in the near past, and for now, are seemingly indifferent of humans and their activities, but only until disturbed by unlucky spacecraft passing too close to places of their new habitat.

These are also in order of current completion, both in terms of concept/idea and gameplay vise - from most to least. 

At the moment Pirate forces are the most thought-out and developed group, so today I'll mostly tell you about them.

Plotwise, Pirates are constantly attacking solo miners, but are especially interested in Player due to them possessing a certain gadget mentioned already in the first devlog. Most of your encounters with their forces are going to happen while you are warping from sector to sector, as they chase you from the start of the run. However, there are also plenty of small groups and single ships minding their business in almost all places, and it's up to the player to decide - to clean them one by one, or spend the time, otherwise used to do it, for something else - at risk of some of them joining the chase group.

Pink dots - rogue enemy groups marked on the sector map

Threat-meter, showing accumulating enemy forces and some other stuff

While the diversity, power, and density of all enemies depend on how far have player has gone in the current run, the pirates' chase group has one more source of scaling - time spent in the current sector. Such a mechanic made the most sense to me from the start of the development, both in a logical way - the longer they know where to find you at the moment, the more forces are joining in to assault you - and gameplay-wise - it forces the player to manage their time while constantly making a decision: either to spend more time improving their gear in preparation to face a stronger enemy or to speedrun through sectors and gather only the most essential and needed stuff.

All enemies are planned to drop money, resources, and in rare cases (mostly bosses) - equipment and/or blueprints of such.

Some of the earliest concepts: 4 pirate ships to the sides and a single cultist exemplar at the center

At the moment Pirate forces are the most thought-out and developed group, so today I'll mostly use them to show what's already done in the game. The image above contains ideas for the next enemy units, from left to right:

1. Simplest of all at the moment, pirate forces' Light Fighter; is used to distract the player's attention from more dangerous units,
but can be easily dealt with on its own.

2. Rocket Gunship of the same enemy fraction, slightly more advanced and deadly than a previous one;

3. Cult's Standard Fighter (won't tell you much about it for now but here's half-finished concept art;

4. Pirate Medium Fighter - it's almost the same as a light one, but tankier and deadlier at the cost of maneuverability;

5. Pirate Kamikaze Drone - small, highly maneuverable,and serving a single purpose - to take out a good part of your hull or shield
using a powerful explosive payload. One-time use (obviously (or is it?))

In a game such as what I envision Astefactor to become Player is constantly getting stronger throughout a run - both with numeric stat-ups and whole new abilities, and I think it's pretty logical to make enemies do the same.

Numerically, enemies just get tankier and deadlier with each Layer of a run the player passes. A layer is a group of Rings, which are groups of individual Sectors the run consists of. They also differ thematically, but that's a topic for the next devlog. For now - imagine layers as an analog for EtG's floors or TBoI chapters. This growth is pretty sensible and requires the Player to keep up - by growing their numeric stats accordingly via spending resources to improve their equipment.

On the other hand, not only next layers bring new enemy types, but also new abilities and attacks for the old ones, partially with the help of the mechanic described next.

While individual enemy units do experience these two growth types simply by the player advancing towards the end of a run, there's one more growth direction, and it affects enemies depending on how long the player stays at a single sector, as well as on percentage of rogue units left in previous ones. This direction is simply an amount of units you need to endure before warping to the next sector - but there's a catch: I didn't want my game turning into another Vampire Survivors clone somewhere in the middle of a run, for two reasons:
- I want to deliver a completely different combat experience
- I want to use GDScript for everything, so performance is one of my concerns - with the current implementation game can smoothly handle something around 200 enemies and their projectiles, and this is important - most of the enemies need to shoot at the player and not just chase them like in your typical Vampire-like.
I also need to consider that PCs of most of potential players are not as powerful as my developer machine.

The solution I found is really simple yet can provide some really neat ways to balance and diversify the combat: I just need to merge weaker units to create stronger ones!

Merge can occur up to 3 times and comes with two effects: firstly, the stats of a new unit become some fraction of the combined values of all merged into it; at the same time, the unit increases it's "tier", possibly (most of the time) changing its behavior in some way and acquiring new tools to cause more trouble to the player.

For now Tier is only visually distinguished by colors

This process also only occurs when there are too many enemies of the same type. In-game logic, it simply means requiring not only an amount to merge but also a minimal number of enemies of the previous tier to remain the same. 

For example, Pirate Light Fighter requires only two copies to merge, yet there must remain at least five more after this. So, a pack of 20 will only merge 14 into 7 Tier-2, of which only 2 will become 1 Tier-3, resulting in a total of 6 Tier-1s, 5 Tier-2s, and a single Tier-3 unit.

At last, certain ranks can only become available to enemies only after the player reaches a certain Layer.

Here's a current model for Light Fighter's tier progression, though only Tier 1 is implemented for now:
Tier 1 - circles the player, firing two simple shots in quick succession once in a while;
Tier 2 - nonlinear orbit speed;
Tier 3 - shield (which is a separate mechanic and not a part of this devlog)) + orbit dashes to make hitting it even more difficult;
Tier 4 - heavier fire barrages + speed up on low health;
Tier * - self-d dash on low health. What's a "*" Tier, you may ask? Idk lol

I think it's enough for now, the topic is so important that it won't be possible not to touch it again and again in all the next posts.

Speaking of the next post, it'll most probably be about run structure as a whole, as well as about the main game loop.

Also, in case anybody is interested in the programming side of the things I describe here - there will be at least one (probably more) separate post(s), telling in packs about all the systems of a game I consider were at least somewhat interesting or challenging to implement.

Here are some visuals of a certain object that takes a really important role in your progression through the run and will be told about next time.

Feel free to tell or ask me anything about what you've read or seen, and thank you for reading! See you next time.