Show us your in-development game! - Gamdev's Septemberbash 2021 Showcase! [closed]

My game is Knights Province - it is an RTS set in middle ages. Think "Settlers 4" or "Stronghold" or "Knights and Merchants". Previous stable Alpha 11.3 is available at game's website. Newer builds and discussion are on Discord.

Recently I've been working towards releasing a new big Alpha version. Each new Alpha has several big features and a lot of minor improvements.

• What's the most recent feature you've got in?

  That will be sheep farms and pastures. It is a new kind of a building in the game that needs an enclosed area next to it (pasture) where sheep will graze and grow and produce wool. This feature has several aspects to it:

  1. Makes the town look more alive with cute little sheeplings
  2. It's a mini-planning challenge for a player to place the pasture
  3. Adds variety to town-building

• What are you the most proud of so far?

  Offtopic: that the game is coming out good enough to be actually played :-D

• What's been the hardest part to do so far, why, and how did you managed to get over it?

  I would say it was 2 things:

  1. Less technical hard part was to come up with and lay out the game mechanics and players UI (in a broad way) of the feature. What player should do, what can go wrong, what is not intuitive and how can it be worked around. Playtesting is the key to the solution here. If it does not feel right or fun - it should be changed.
  2. More technical hard part was with the scope of the feature - one word "pastures" immediately brings in the fences, more detailed object picking, more complicated pathfinding, attackable and destroyable fences, fence selection in UI and cherry on top - "teaching" AI how to build and handle them. (Related question - How to maximize enclosed area and minimize perimeter on a grid with obstacles? ). A lot of code had to be refactored and added. Decomposition was the key - everything had to be split into manageable parts and each one be well isolated, so that parts could be solved one at a time and if needed, "stubbed" until solved (replaced with a hardcode).

• What part do you think will be the hardest to complete in the near future?

  As of right now, the gameplay and feel of the feature is kind of "okay". The hardest part will be making it more fun to play with. Also the diminishing returns - each new small improvement in fun/technical aspect will require more and more work. Keeping motivated is definitely needed for that!

• What's a cool trick or solution you found that others might find useful?

  When you have mocked up and prototyped the feature and it starts to look like it is going to stay - spend time on making its debug displays and outputs, so that you can track its every little detail. The more complex the mechanics are, the more help from "inside the black box" you will need later on to efficiently work on them.

I haven't named mine yet - for now it's just a "3D Game". It will focus on exploring and fighting through procedurally generated worlds with traditional RPG like might-and-magic mechanics. It is intended to be single player, although I am considering possibility of some kind of very limited local multuplayer, or at the very least AI companions to team up with for the harder battles.

A lot of design decisions are influenced by existing games, such as WoW or Minecraft or Hellgate London (the old one).

It is all on GitHub, I haven't put a license yet, but I mean for it to be open source so others can learn from it or come up with improvements. The code (and some outdated screenshots) can be seen at https://github.com/htmlcoderexe/3DGame.

I am currently working on item generation - there is some stuff I haven't committed yet, but the most recent committed thing involves generalising item "types" - I am trying to have it as data driven as possible. Character classes and abilities are already completely separate from actual code (although ability effect components are still hardcoded, I do not think this is avoidable, they are more like opcodes anyway). Now I also have items in broad categories (three classes of armour, accessories, ranged/melee/magic weapons etc), while actual item "types" are then used in game. These types decide the stats of the finished item based on its level, as well as its equipment slot, and description in the ingame view.

For example, a "Poleaxe" is a Melee weapon, with [some amount of] Physical Attack added per level. It equips into the Weapon slot and can have either of these three icons.

I actually used to have those hardcoded enums and arrays of stat growth and names and all bunch of stuff per equipment type - now it's all in a file somewhere, easily editable.

I think related to this is the actual editor app that I made - it's somewhat similar to the "Game Editor" window from RPGMaker, with all the different tabs for stuff. I now have a working tab for editing the character classes, with editable ability trees, another one for abilities, and now also the item types. It is using Windows Forms, I should probably move on from that, the GUI code is very annoying to manage, although #regions help a lot. Here it is in action:

Class editor with skill tree:

Selecting prerequisite skills:

The red lines are going to be fancy little arrows in the actual game, but at the moment the skill tree displays as is in there.

Another cool thing I did was a special kind of GUI tinting that only targets grayscale, which makes it almost like a rich colour palette swap. I use this extensively in drawing all the randomly generated item icons. I have done a small writeup here:

https://www.reddit.com/r/gamedev/comments/6bze8v/improved_spritebatch_tinting_for_monogame_or_xna/

I actually have an entire GUI system with a window manager, windows, controls, text input, events and dialogue boxes. I have been able to "rip it out" and successfully put it into another game project with minimal adjustments.

The hardest things so far are graphics, hands down. This is using the MonoGame framework (started out as XNA), and there is a lot of code that is needed to make the basics happen. I have my own models, terrain etc, even animation and billboards - I really have to thank Riemer and his tutorials from eons ago to get me started on the whole thing. I still have a lot to do to make it go smoothly (I rather inefficiently have a big Model instance for every single object that's out there at the moment, no particle pool and my animations don't slerp which means ugliness unless each rotation is like 10+ fps matrices).

Getting the terrain chunking right was definitely a pain too - both working with the special data type I created for the purpose that defines every position (a Vector3 for fine float coordinates and a pair of integers for chunk coordinates) as well as making generation align. Now it is mostly working and is probably easily portable to another project - it even has its own very cheap collision detection - it simply interpolates the heightmap.

I am afraid that proper collision detection for everything else that is not terrain will be the hardest thing to implement, though. I am talking about things like dungeon walls and stairs and buildings and all that kind of stuff. I am delaying this until a while later because right now there are all these other things I should be fixing too - I feel that I should have something with more playable functionality before going for the marathon that implementing such collision would be.