7
\$\begingroup\$

The vacation season is coming to an end, and while it has been a moment to rest and have a good time with the ones we love, it has also been a good time for some of you to work hard on your next game.

Here we're proposing that you show us what you've been working on recently toward making your next game!

You can share with us

  • What's the most recent feature you've got in?
  • What are you the most proud of so far?
  • What's been the hardest part to do so far, why, and how did you managed to get over it?
  • What part do you think will be the hardest to complete in the near future?
  • What's a cool trick or solution you found that others might find useful?

Your game is eligible if:

  • It is a work in progress, meaning either an unreleased game, or an update/extension/DLC in development for a released game.
  • It is SFW (Safe-for-Work)
  • Its content respects the StackExchange Code of Conduct and Acceptable Use Policy, including but not limited to...
    • No bigotry.
      We don’t tolerate any language likely to offend or alienate people based on race, gender, sexual orientation, or religion — and those are just a few examples. Use stated pronouns (when known). When in doubt, don't use language that might offend or alienate.

    • No harassment.
      This includes, but isn’t limited to: bullying, intimidation, vulgar language, direct or indirect threats, sexually suggestive remarks, patterns of inappropriate social contact, and sustained disruptions of discussion.

    • Sexually Explicit Material. Accounts that use Stack Exchange to post sexually explicit or pornographic material, or links to it, will be suspended. If you think the content of the game is not safe for everyone, please make sure you add a warning notice to your answer, something like an ESRB content descriptor.

Rules for posting answers:

  • You must have asked at least one question, or provided at least one answer on the main site between September 1st 2020 and September 1st 2021.
  • One game per answer
  • Introduce your game first
  • You can link to your game's site or Steam/App Store page, but the answer can't be a link only one: please tell us about your work!
  • The links you provide must link directly to the game site, it must not be a "short link" such as bit.ly, or include some kind of redirection.
  • Submissions will close after September 30th
\$\endgroup\$
4
  • 2
    \$\begingroup\$ Love this idea! Thanks for getting this going! \$\endgroup\$
    – DMGregory Mod
    Sep 1 at 17:08
  • \$\begingroup\$ There was another post here, where did it go? too bad I dont have 10k rep to see for myself \$\endgroup\$
    – Kromster
    Sep 22 at 13:50
  • 1
    \$\begingroup\$ @Kromster Looks like you'll need to keep on the good work here to find out ;) \$\endgroup\$
    – Vaillancourt Mod
    Sep 30 at 21:33
  • \$\begingroup\$ The submission period has ended. Thanks all for the interest shown! \$\endgroup\$
    – Vaillancourt Mod
    Oct 1 at 0:22
7
\$\begingroup\$

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.

enter image description here

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.

\$\endgroup\$
3
  • \$\begingroup\$ Thanks for sharing this with us! I'm not sure I understand what you mean by your last paragraph? Do you mean that debugging those features is more complex and don't get solved by adding debug related graphics widgets and such? \$\endgroup\$
    – Vaillancourt Mod
    Sep 10 at 15:06
  • \$\begingroup\$ @Vaillancourt thanks for the feedback! I have tried to reword it. \$\endgroup\$
    – Kromster
    Sep 10 at 18:24
  • \$\begingroup\$ Ah, I understand now, thanks for clarifying :) Good luck with the next steps! \$\endgroup\$
    – Vaillancourt Mod
    Sep 10 at 19:10
3
\$\begingroup\$

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:

screenshot

Selecting prerequisite skills:

screenshot

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.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Keep up the good work, thanks for sharing this with us! \$\endgroup\$
    – Vaillancourt Mod
    Sep 30 at 13:52
  • 1
    \$\begingroup\$ I am happy to show this to others, I hope someone will find useful information or ideas from this. \$\endgroup\$ Oct 2 at 19:56

Not the answer you're looking for? Browse other questions tagged .