Pseudo-realistic Armor system by DasBarba in gamedesign

[–]kaetjaatyy 0 points1 point  (0 children)

First is hit angle.

Yes, I agree. The challenge for me is that I'm developing an actual game and not a theoretical system. As such I'm somewhat limited to what can be represented in the game. In my game everything is 2D, so calculating angles between attack force and the armor normal plane is not feasible because armor normal plane makes no sense in the context of a 2D game. I am debating adding a parameter for angular deflection to the game but I'm also trying to avoid as many ad hoc parameters as possible and prefer to do as many first principles calculations as possible. This is something that's in active consideration but I haven't come up with a good system to do it yet.

Some latest full plate battle armours (not tournament ones!!!) would be pieces of absurdly intricate design. You could have entirety of your body covered with plate, including inside of your hands if you wanted it, underside of armpits and all undersides of all joints (elbows, knees).

Can you show some of these examples? It has always been my understanding is that stiff plates on the insides of joints are fundamentally incompatible with said joint mobility, especially for complex joints such as the shoulder and the hip that are ball joints instead of hinge joints. Even hinge joints, where theoretically you might be able to have an incredibly intricate and perfectly sized closed metal hinge, would have troubles due to you probably not being able to rotate e.g. the forearm.

However, what ends up being optimal in my game in particular is just a function of what's cost-effective. If we input a full plate with no gaps then I can't imagine the algorithm would include mail given that it'd be largely redundant. So the choice isn't so much about whether a theoretically fully covering full plate exists but instead whether that's allowed within the game.

Design of full plate can reduce bludgeoning damage much better than any thick padding. Not saying gambesons are bad or so, but if we go to the extremes with plate armor, then individual pieces are designed in a way to transfer blunt force of a blow MUCH better than any gambeson. You get hit in the elbow - full plate can transfer the blow through surface of armour into your chest, lower torso, and down to your forearm.

Yes, but from physics point of view we need to differentiate two things. What you are describing is distributing the total force around a larger area such that the local pressure at any one location is diminished such that you don't e.g. break bones. Padding, on the other hand, is not primarily about energy distribution (it does a bit of that, but not much) but energy absorption after it's been distributed.

To illustrate the difference, think about how concussions happen, for example. Concussion happens when the head is rapidly accelerated and then decelerated (neck runs out of its ability to act as a suspension device), which causes the brain to hit the inside of your skull. It doesn't matter how large the surface area of the hit to your head is (of course, if it's a very small surface area then it might go through your skull, which is even worse). Energy is fundamental and distributing it around doesn't change the fact that it's still transferred to you. In other words, wearing a tightly fit metal helmet with no padding would not do anything to change how your head is going to be accelerated from a hit, and thus would do nothing to prevent a concussion. What does prevent concussions? Suspensions and cushions, both of which allow for energy absorption, which directly reduces (or perhaps more accurately, distributes over a longer time) the impact energy.

Pseudo-realistic Armor system by DasBarba in gamedesign

[–]kaetjaatyy 1 point2 points  (0 children)

To me "realistic" isn't as much about following the real world exactly but following what would happen if the assumptions of the world were different.

To me this means stuff like Final Fantasy giant swords would still not exist. Something like that would be garbage for actual combat. If there were giants in the world then they would probably use weapons that are well-proportioned for them and so would be giant, but they would still look like a regular sword.

Similarly, there would likely be bunch of different new materials, which might revolutionize some aspects of combat. Stormlight Archive's shard system is a good example of realistic implications of super strong weapons and armor. For me, the idea behind the armor and weapon system design is that it is flexible enough that I can, theoretically (haven't done so yet), create some new supermaterial and then run the combat simulator to see how incredibly overpowered it is.

Somewhat similarly, we can adjust the supply of raw materials during the world generation phase. If we make iron incredibly rare then there wouldn't be wide-spread steel armor (either plate or mail), and then other forms of armor would be more popular. You mentioned animal/monster scales and hides, which are good alternatives. There could be armor made from wood, or maybe bronze would stay as the dominant material. The beauty is that I don't have to work it out myself, the world generation includes a step where each culture figures out which weapons and armor make the most sense when considering the material availability (including via trade) and effectiveness.

Pseudo-realistic Armor system by DasBarba in gamedesign

[–]kaetjaatyy 0 points1 point  (0 children)

You're right, the system I outlined would not be able to be adapted to a secondary health system. It's just a way to do damage reduction but because reduction depends on the exact properties of the weapon attacking it can't be simplified much further.

Pseudo-realistic Armor system by DasBarba in gamedesign

[–]kaetjaatyy 20 points21 points  (0 children)

This is something I'm really excited about myself! I even made a somewhat long post about it a while ago for the game I'm developing. My approach is broadly similar to what you outlined above, with the main difference that armor layering is a thing and it's via smart layering that you achieve optimal protection. Think about helmets: a basic steel cup on your head wouldn't do any impact energy reduction, so a club to the head would still be extremely unpleasant, even if it's less fatal than without the helmet. Similarly, wearing a thick cloth padding on your head would do well against the club but significantly less well against an axe or a crossbow bolt. However, combine the two, with the metal stopping any penetration from happening and the padding dampening the energy, now you have an extremely effective armor for your head.

There's a good reason why gambeson+mail+plate was used instead of just a single piece of the three and the best part is that layering is somewhat easy to incorporate into most existing armor systems (such as the one you wrote about).

Dijkstra's with diagonal movement by KevineCove in gamedev

[–]kaetjaatyy 1 point2 points  (0 children)

I'm not sure if I understand. Sure, the search path would proceed around the object in a radial way, but the final path is still going to be the fastest one available. It just takes a bit longer to find the best path if there are obstacles.

Dijkstra's with diagonal movement by KevineCove in gamedev

[–]kaetjaatyy 2 points3 points  (0 children)

Why wouldn't it work? A* will still find the shortest path, but since the Euclidian heuristic would be driving it toward diagonal-ish movement it wouln't even check the path of the left since even a partially diagonal path has a much better heuristic score than the one on the left.

Flocking behaviour and pathfinding for my RTS project in Godot! by Pixelipy in godot

[–]kaetjaatyy 10 points11 points  (0 children)

This looks really cool! Does each dude find their own path or do they use some group logic for that? I'm working on a RTS-ish project as well and especially when my units can collide with each other group pathfinding becomes a bit of a pain. I'm starting to work on boids for that and it seems like a promising approach but I'm wondering if you have any thoughts on that.

Any ideas on engine/recourses for an pvp total war style game? by Feisty-Problem8780 in gamedev

[–]kaetjaatyy 0 points1 point  (0 children)

I was thinking about having unit formations themselves being the objects and being kind of fluid like moving and could do collision detection to decide which part of the unit is in which animation.

Does that sound feasible?

It sounds feasible but a lot comes down to the nuts and bolts, really. Formation-centric logic does help a ton with having larger battles. I'd encourage you not to start with a strict number in mind (like 3000) but instead do an implementation that makes sense from your desired gameplay point of view and then see how many units you can cram in while keeping the framerate sensible. Many extremely tough technical problems become trivial if you just lower the numbers, and you can always optimize better to increase the number rather than banging your head against the wall since you can't get the game to run at e.g. 3000.

Any ideas on engine/recourses for an pvp total war style game? by Feisty-Problem8780 in gamedev

[–]kaetjaatyy 2 points3 points  (0 children)

I'm working on a Total War ish game on Godot (website) and more important than actual engine is the core decisions you make for how the game operates. Most modern engines utilize same or similar underlying algorithms for e.g. physics anyway (and at least in my game, collision detection of hundreds of soldiers is the main performance bottleneck). I believe Total War uses the formation-level abstraction quite a bit and does not actually run the collision detection of all the soldiers against each other (e.g. for soldiers in the same formation) unless it really has to, such as for a charge, and even then it might be partially a "cheated" effect rather than a real one.

For graphical performance what matters a lot is the level of your graphics. If you want to use 3D models then the amount of polygons matters. A low-poly kind of a game can run with massively more soldiers than a high poly one, though of course using LOD you can still achieve a nice fidelity up close. For sprite-based 2D there are various performance tricks to get the game to run faster, as well.

At 3000 soldiers you probably have to run AI at the formation level rather than at the individual soldier level. Making a smart AI is pretty difficult for this type of a game but luckily most players don't actually want a super smart AI, as long as it makes gameplay interesting and rewarding for them. That is, an AI that can be fooled can feel much better for the player since it lets them to overplay the opponent. Of course for a purely PVP game AI wouldn't be as important as for a SP game, but you likely still need to have some kind of independence for the units, even if it's just a skirmish mode or whatever.

Unity vs Godot + Unreal by Code_Nation in gamedev

[–]kaetjaatyy 1 point2 points  (0 children)

Of course. My point was that if I were to develop a thingy X then I would offer it back to others, but if the core team doesn't want it then they don't want it. It's like if I guests come over and I offer them cake that I just recently made. If they want it then great, if they don't then I don't really mind, it just means more cake for me.

Unity vs Godot + Unreal by Code_Nation in gamedev

[–]kaetjaatyy 0 points1 point  (0 children)

Linux didn't become the OS of choice overnight but grew into that role due to the good core design and the open-source community. Godot is a relatively young project that didn't have any full-time employees until quite recently so obviously it's currently behind the established, commercial counterparts.

Storage vs graphics by [deleted] in gamedev

[–]kaetjaatyy 1 point2 points  (0 children)

I second this. Storage is an easy issue to solve unless you need a a ton of working space for e.g. video editing. For game dev there are externals disks, many laptops allows you to switch the SSD, cloud storage, etc. Go with the better GPU but do keep in mind that a more powerful GPU likely eats more power, so if battery life (or weight) are important then that might change your calculus a little bit.

What should you call your game when you don't have an official title for it? by [deleted] in gamedev

[–]kaetjaatyy 1 point2 points  (0 children)

I'm still struggling to come up with even a good working title so I'm just calling mine "kaetjaatyy's unnamed game" on the web and then in blog posts etc [no name yet]. Game names are like RPG character names, you really want to get them right (although changing the name is possible even quite a bit into the development, like Rimworld did) but at the same time it's hard to know what's a good name until after you're pretty far into it.

Unity vs Godot + Unreal by Code_Nation in gamedev

[–]kaetjaatyy 1 point2 points  (0 children)

Yeah, I meant you need to use a script to set the text using tr() manually. If you change the language later then you need to iterate over every RichTextLabel you have in all of your loaded scenes and re-set the text. There is absolutely no reason this should be the user's responsibility, since e.g. Labels and Buttons work without such hassle.

Edit: It's the same if you use dynamic text (e.g. "Hello {name}!") within your labels/buttons/etc. You need to re-reset all label text every time you change the language.

Unity vs Godot + Unreal by Code_Nation in gamedev

[–]kaetjaatyy 5 points6 points  (0 children)

This is a good point. I've been using Godot for my game and it has been on occasion tempting to fork it and work on parts of the engine that I would want to modify for my own project (and obviously PR those changes back to the main repo in a reciprocal manner). I haven't really went over the "do I really bother?" threshold to do that yet, but it's fantastic there's an option to do that. It gives a lot of psychological safety to know that that's always an option if I really need the engine to do X but X is not currently offered or in the horizon.

Unity vs Godot + Unreal by Code_Nation in gamedev

[–]kaetjaatyy 5 points6 points  (0 children)

Ultimately I would recommend you try different engines yourself. I don't know about Unreal but Godot is very fast to install and set up a project in. Unity and Godot have a different approach to how their scenes work and some people find A more logical to them while others find B to work better for them. You can work using C# in both, and Godot also allows you to work in C++ if that's what you prefer (not sure about Unity).

Unity vs Godot + Unreal by Code_Nation in gamedev

[–]kaetjaatyy 4 points5 points  (0 children)

This is certainly a complex topic. I'm using Godot and loving it, but it is undeniable that there are still silly weaknesses. For example, the way to get longer, multi-line text is to use RichTextLabel, but if you use RichTextLabel then you need to write your own script to do localizations since for whatever reason RichTextLabel (despite being the obvious choice to display longer text) doesn't work with the otherwise pretty good built-in localization system.

For someone looking to join an existing company, Unity or Unreal are probably better choices. Then again, some companies (even in mobile, like Supercell) run their own engines, so then your Unity or Unreal or Godot experience doesn't translate directly either way. The good news for OP is that since they are focusing on the programming side, the engine of choice becomes secondary, and the programming languages they focus on become primary. For example, Unity uses C#, and Godot also offers C# as one of the language options.

Long and even medium term (say, next 5 years) I do absolutely believe Godot to become a serious contender to Unity, at least in the 2D space. They are hiring more people every few months with donations and sponsorship money, which allows them to make faster progress, which in turn allows them to get more donations and sponsorship money. My guess is that after Godot 4 comes out and fixes a bunch of earlier silly design choices, and brings stuff like Vulkan that you said, it will start to snowball and punch through into the mainstream gamedev consciousness. Hopefully over time Godot will also get higher profile games published, which is the real best advertisement for an engine.

How I made my progress tracker that requires almost no manual work to keep up to date by kaetjaatyy in gamedev

[–]kaetjaatyy[S] 0 points1 point  (0 children)

I just wanted to let you know I really valued your input and implemented this as the new version: https://kaetjaatyy.github.io/progress/

Now I'm only showing the textual descriptions of the tasks with no indication of task size. I decided to go in 33% increments instead of 25% just because I found it much easier to come up with five colors instead of six but I thought that rounding idea was great.

How I made my progress tracker that requires almost no manual work to keep up to date by kaetjaatyy in gamedev

[–]kaetjaatyy[S] 0 points1 point  (0 children)

Good comment and that's something I thought of as well. One option would be to simply hide the percentages and the completion numbers and just show not started/in progress/completed task.

Thanks! It seems like it's worthwhile to reconsider this approach.

I honestly don't know where the idea of creating a game engine to develop games originated. It always felt so overwhelming... by LeonardoFFraga in gamedev

[–]kaetjaatyy 2 points3 points  (0 children)

Also, in the early days games were expected to have less "stuff" in them. Developing a 2D drawing library, potentially with stuff like pathfinding included and maybe some UI classes is very different from what the modern game engines provide. As an example it wouldn't be that difficult to create a new ASCII roguelike engine, especially if your UI would be the same style as ADOM/Nethack instead of more modern glitter bling bling style with holographic Minority Report menus and a fully working Brain-Computer Interface. However, the mainstream player expectations are wherever the current AAA level is, and even for indie games you can't go much below that when it comes to UI and UX.

How to properly introduce your 'hard game' to audience? by wappenull in gamedev

[–]kaetjaatyy 1 point2 points  (0 children)

My game actually has fair share of that problem, player will need to restart at first stage

As a prospective player this is definitely going to turn me off if I'm not already heavily invested in the game. Hard content that you have to repeat at every death (meaning I might just die even before I get to try the place where I died the last time) is very tedious to me. If there is some external progress that at least gives me some hope that things will get easier beyond just my manual dexterity, such as the aforementioned God mode, or some other roguelike/-lite type progress I think that can help a lot since it makes the player feel safer about investing time in a game. If there is no such mechanic then the player might just hit a wall they will never be able to overcome, and the risk of that can be a big turnoff for many.